The document provides an overview of entity relationship diagrams (ERDs) including their basic components, different notations, and how to implement various relationship types in a relational database. ERDs depict entities, attributes, and relationships in a conceptual database design. Key points covered include the three main notations of ERDs, solving multi-valued attributes and many-to-many relationships, and how to implement one-to-one, one-to-many, and many-to-many relationships through primary and foreign key constraints.
Peter Chen developed entity-relationship (ER) diagrams in 1976 to model databases. ER diagrams use entities (objects), attributes (data about entities), and relationships (connections between entities) to represent the structure and semantics of data. Developing an ER diagram helps database designers and analysts better understand the information to be stored in a database by modeling the entities, attributes, and relationships visually.
This document provides an overview of entity-relationship modeling as a first step for designing a relational database. It describes how to model entities, attributes, relationships, and participation constraints. Key aspects covered include using boxes to represent entity types, diamonds for relationship types, and labeling relationships with degrees. The document also discusses handling multi-valued attributes and deciding whether to model concepts as attributes or entity types.
The document discusses the relational database model. It was introduced in 1970 and became popular due to its simplicity and mathematical foundation. The model represents data as relations (tables) with rows (tuples) and columns (attributes). Keys such as primary keys and foreign keys help define relationships between tables and enforce integrity constraints. The relational model provides a standardized way of structuring data through its use of relations, attributes, tuples and keys.
This document discusses the entity-relationship (ER) model for conceptual database design. It defines key concepts like entities, attributes, relationships, keys, and participation constraints. Entities can be strong or weak, and attributes can be simple, composite, multi-valued, or derived. Relationships associate entities and can specify cardinality like one-to-one, one-to-many, or many-to-many. The ER model diagrams the structure and constraints of a database before its logical and physical implementation.
The document discusses the entity-relationship (E-R) data model. It defines key concepts in E-R modeling including entities, attributes, entity sets, relationships, and relationship sets. It describes different types of attributes and relationships. It also explains how to represent E-R diagrams visually using symbols like rectangles, diamonds, and lines to depict entities, relationships, keys, and cardinalities. Primary keys, foreign keys, and weak entities are also covered.
Normalisation is a process that structures data in a relational database to minimize duplication and redundancy while preserving information. It aims to ensure data is structured efficiently and consistently through multiple forms. The stages of normalization include first normal form (1NF), second normal form (2NF), third normal form (3NF), Boyce-Codd normal form (BCNF), fourth normal form (4NF) and fifth normal form (5NF). Higher normal forms eliminate more types of dependencies to optimize the database structure.
Functional dependency defines a relationship between attributes in a table where a set of attributes determine another attribute. There are different types of functional dependencies including trivial, non-trivial, multivalued, and transitive. An example given is a student table with attributes Stu_Id, Stu_Name, Stu_Age which has the functional dependency of Stu_Id->Stu_Name since the student ID uniquely identifies the student name.
The document discusses different types of joins in database systems. It defines natural join, inner join, equi join, theta join, semi join, anti join, cross join, outer join including left, right and full outer joins, and self join. Examples are provided for each type of join to illustrate how they work.
3 data modeling using the entity-relationship (er) modelKumar
This document provides an overview of the key concepts in entity-relationship (ER) modeling for database design. It begins with an outline of the database design process and an example database application for a company (COMPANY). It then defines the core components of ER modeling, including entities, attributes, relationships, relationship types, and ER diagrams. The document presents the initial ER design for the COMPANY database and refines it by introducing relationships. It also covers additional concepts like weak entity types, constraints, and recursive relationships. The overall summary provides a high-level introduction to ER modeling concepts and how they are applied to design a sample database schema.
Entity Relationship Diagrams (ERDs) are conceptual data models used in software engineering to model information systems. ERDs represent entities as rectangles, attributes as ellipses, and relationships as diamonds connecting entities. Attributes can be single-valued, multi-valued, composite, or derived. Relationships have cardinality like one-to-one, one-to-many, many-to-one, or many-to-many. Participation constraints and Codd's 12 rules of relational databases are also discussed in the document.
This document provides an overview of relational database management systems (RDBMS). It defines key database concepts like data, information, and database systems. It also explains the hierarchical structure of DBMS and compares flat file databases to relational databases. Relational databases incorporate multiple normalized tables that can be related to each other, while flat files put all data in a single table without relationships between files.
This document discusses advanced data modeling concepts in database systems, including the extended entity relationship (EER) model and its main constructs such as entity supertypes, subtypes, and clusters. It covers specialization hierarchies, inheritance, subtype discriminators, and guidelines for selecting primary keys. Special design cases demonstrate flexible design approaches and proper identification of primary keys and foreign keys.
This document provides an example of student records in an unnormalized form, containing repeating groups. It then demonstrates normalizing the data by removing the repeating groups into multiple tables in first normal form. Further normalization results in separating attributes with partial dependencies and non-key dependencies into their own tables, achieving second and third normal form respectively. The document explains the different normal forms and how normalization helps reduce data anomalies on insert, update and delete operations.
The document discusses database design and relational database management systems. It covers key concepts like normalization, primary keys, foreign keys, and relationships between tables. Normalization is the process of organizing data to eliminate redundancy and ensure data is stored correctly. There are five normal forms with third normal form being sufficient for most applications. Tables are related through primary and foreign keys and different types of relationships can exist between tables like one-to-one, one-to-many, and many-to-many.
Normalization is a process used to organize data in a database. It involves breaking tables into smaller, more manageable pieces to reduce data redundancy and improve data integrity. There are several normal forms including 1NF, 2NF, 3NF, BCNF, 4NF and 5NF. The document provides examples of tables and how they can be decomposed into different normal forms to eliminate anomalies and redundancy through the creation of additional tables and establishing primary keys.
This document is from a textbook on database systems. It introduces fundamental concepts such as what a database is, the role of database management systems, and typical database functionality including defining schemas, loading data, querying, and concurrency control. It also discusses different types of database users and the advantages of the database approach such as data sharing and integrity enforcement. Examples of entity-relationship diagrams and database relations are provided to illustrate conceptual data modeling.
This document discusses relationships in database management systems. It begins by introducing relationships and how they are established through primary and foreign keys. It then describes different types of relationships: one-to-one, one-to-many, many-to-one, and many-to-many. For each relationship type, it provides examples and descriptions of how the relationships are implemented in tables. The document emphasizes that relationships are important for reducing data redundancy, organizing the database, and ensuring referential integrity. It concludes by reiterating the importance of properly defining relationships for effective database functioning.
This document discusses the relational data model and SQL. It begins with an overview of relational database design using ER-to-relational mapping. It then discusses relational model concepts such as relations, attributes, tuples, domains and keys. It also covers integrity constraints and SQL components like data definition, data types, and retrieval, modification and deletion queries. The document outlines topics such as relational algebra, calculus, and features of SQL like views, triggers and transactions. It provides learning objectives and expected outcomes of understanding these concepts.
The document provides information on entity relationship diagrams (ERDs), including the objectives, components, and steps to create an ERD. It defines key ERD concepts like entities, attributes, relationships, and cardinality. It describes the entity modeling process and discusses how to recognize entities, attributes, relationships, and cardinalities in a database. It outlines the general steps to create an ERD, including identifying entities, finding relationships between entities, drawing a rough ERD, defining primary keys, identifying attributes, mapping attributes to entities, and drawing a fully attributed ERD. Sample ERDs are provided to illustrate concepts like cardinality constraints.
Informational Referential Integrity Constraints Support in Apache Spark with ...Databricks
An informational, or statistical, constraint is a constraint such as a unique, primary key, foreign key, or check constraint that can be used by Apache Spark to improve query performance. Informational constraints are not enforced by the Spark SQL engine; rather, they are used by Catalyst to optimize the query processing. Informational constraints will be primarily targeted to applications that load and analyze data that originated from a data warehouse. For such applications, the conditions for a given constraint are known to be true, so the constraint does not need to be enforced during data load operations.
This session will cover the support for primary and foreign key (referential integrity) constraints in Spark. You’ll learn about the constraint specification, metastore storage, constraint validation and maintenance. You’ll also see examples of query optimizations that utilize referential integrity constraints, such as Join and Distinct elimination and Star Schema detection.
This document discusses displaying messages and alerts in Form Builder. It describes using built-in functions like ERROR_CODE and MESSAGE_TYPE to identify error types. Form Builder can display default, informative, and error messages. Alerts can be created and customized at runtime using properties and buttons to handle different responses from the user. Built-in functions like FORM_SUCCESS and FORM_FAILURE help test for success or failure.
The document discusses how to represent optionality in entity relationship diagrams (ERDs). It explains that ERDs typically show cardinality but not whether relationships are mandatory or optional. To denote optionality, a vertical line or hollow circle is placed next to the cardinality. Examples show mandatory relationships require a match, while optional relationships may have no match. The document also provides tips on determining optionality and how tools like Visio represent it.
SQL Stored Procedures For My Library ProjectRick Massouh
This document contains the code for several stored procedures used in a library database:
1) It defines procedures for adding adult members, adding items/copies to the library catalog, checking items in and out, and retrieving member and item loan information.
2) The procedures perform validation checks and make transactions atomic by committing or rolling back based on the success of data modifications.
3) Stored procedures streamline common database tasks, promote consistency, and help enforce data integrity constraints for the library application.
This document provides examples of entity-relationship diagrams (ERDs) for various scenarios. The examples cover relationships between professors and classes, courses and classes, invoices and products, customers and items purchased, departments and projects, orders and parts, equipment faults, students and subjects, painters and paintings, car models and parts, university faculties and courses.
The document provides information about entity relationship diagrams (ERDs), including their objectives, components, and how to create them. An ERD is a graphical tool for modeling data and relationships between entities in a database. It identifies the key entities, attributes, and relationships. The summary includes steps to develop an ERD: 1) identify entities, 2) find relationships between entities, 3) draw a rough ERD, 4) define cardinalities, 5) identify primary keys, 6) map attributes to entities, 7) draw a fully attributed ERD, and 8) check the results. An ERD serves to document and communicate the logical structure of a database.
The document provides information on entity relationship diagrams (ERDs), including their objectives, components, and how to construct them. An ERD is a graphical representation of entities, attributes, and relationships within a database. It serves as a design tool, documentation, and means to communicate the logical structure. Key aspects covered include identifying entities and attributes, defining relationships and cardinalities, and using standard symbols and notations to draw the ERD.
Entity Relationship Diagrams (ERDs) are used to model relationships between entities in a database. The document discusses ERD components like entities, relationships, cardinality, and attributes. It provides an example of an ERD for a company with departments, supervisors, employees, and projects. Key entities are identified and their relationships and attributes are represented in the example ERD diagrams.
Integrity constraints are rules that help maintain data quality and consistency in a database. The main types of integrity constraints are:
1. Domain constraints specify valid values and data types for attributes to restrict what data can be entered.
2. Entity constraints require that each row have a unique identifier and prevent null values in primary keys.
3. Referential integrity constraints maintain relationships between tables by preventing actions that would invalidate links between foreign and primary keys.
4. Cascade rules extend referential integrity by automatically propagating updates or deletes from a primary table to its related tables.
Entity relationship diagrams show relationships between tables using lines and cardinality notation. Cardinality describes whether a relationship is one-to-one, one-to-many, many-to-one, or many-to-many. Many-to-many relationships cause data problems and are resolved using a link table to create two one-to-many relationships. For example, a books lending relationship between lenders and books would be resolved using a lend records link table.
The document discusses the relational data model and ER model for conceptual database design. It covers key concepts such as entities, attributes, relationships, constraints, and ER diagrams. The relational data model uses tables made up of rows and columns to store data, with each table representing an entity. Relationships between entities can be one-to-one, one-to-many, many-to-one, or many-to-many. The ER model is used to design the conceptual schema and represent entities, attributes, and relationships visually using diagrams. The conceptual schema is later transformed into a logical schema for a specific database implementation.
The document discusses the Entity-Relationship (ER) model for conceptual database design. It describes the key components of the ER model including entities, attributes, relationships, and keys. It also explains how the ER model maps to a relational schema and database, including the use of tables, rows, columns, primary keys, foreign keys, and integrity constraints. Referential integrity constraints are defined to link tables through foreign key to primary key relationships.
The document introduces database management systems and conceptual database design using the Entity Relationship model. It discusses key concepts such as the universe of discourse, requirements analysis, conceptual schema, entity types, attributes, relationships and constraints. The conceptual schema provides a high-level design of the database that is independent of specific DBMS implementations and easy for non-technical users to understand. This conceptual design forms the basis for later logical and physical database design steps.
Introduction to Database Management Systems Reem Sherif
The document provides an introduction and overview of database management systems (DBMS) including basic concepts, structured query language (SQL), and non-SQL databases. It outlines a course agenda covering these topics over two days, and then delves into explanations of key concepts such as the file-based system approach and its limitations, definitions of database terminology, database users, database system architecture, data models, and entity relationship modeling. Examples are also provided to illustrate database design and entity relationship diagrams.
Chapter-3 Data Modeling Using the Entity-Relationship ModelRaj vardhan
The document describes conceptual database design using the entity-relationship (ER) model. It discusses key concepts of the ER model including entities, attributes, relationships, and relationship constraints. An example ER diagram is presented for a COMPANY database with entities for employees, departments, and projects. Relationships include employees working for departments and departments controlling projects. The summary provides an overview of the important concepts and examples covered in the document related to conceptual database design using the ER model.
This document discusses conceptual data modeling using the entity-relationship (ER) model. It defines key concepts of the ER model including entities, attributes, relationships, entity sets, relationship sets, keys, and ER diagrams. It explains how the ER model is used in the early conceptual design phase of database design to capture the essential data requirements and produce a conceptual schema that can be later mapped to a logical and physical database implementation.
1) The document describes an entity-relationship (ER) diagram for a university database. It identifies the main entities as Department, Course, Module, Lecturer, and Student.
2) The key relationships are that a Department offers multiple Courses, a Course includes multiple Modules, a Lecturer teaches multiple Modules, and a Student enrolls in a Course and takes the Modules required to complete it.
3) The document explains the different components of an ER diagram, including entities, relationships, attributes, keys, and relationship types (one-to-one, one-to-many, many-to-many). It provides examples of how to map an ER diagram to database tables.
Entity type
Entity sets
Attributes and keys
Relationship model
Mapping Constraints
The ER Model
Cardinality Constraints
Generalization, Specialization and Aggregation
ER Diagram & Database design with the ER Model
Introduction
Relational Model
Concepts
Characteristics
Guidelines for ER to Relational Mapping.
Mapping rules/ guidelines for mapping various ER constructs to Relational model with appropriate examples
Relational Query Languages Formal Query Languages
Introduction to Relational Algebra
Relational operators
Set operators
Join operators
Aggregate functions.
Grouping operator
Relational Calculus concepts
Relational algebra queries for data retrieval with sample relational schemas. relational algebra operations.
The document discusses database design concepts including the entity-relationship model, normalization, and functional dependencies. It provides descriptions of key concepts such as entities, attributes, relationships, and mapping approaches from ER diagrams to relational schemas. It also covers normal forms up to BCNF and the goals of normalization to reduce data redundancy and anomalies.
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...Mustafa Kamel Mohammadi
In this chapter you will learn
Relational data model concepts
What is entity?
What is attribute and it’s types
What is relationship?
What is an Entity-Relationship data model?
Relational data model constraints
Characteristics of relation
This document discusses databases and the relational database model. It covers key concepts like data, records, fields, and tables. It also explains entity relationship diagrams and how they are used to represent relationships between entities. Different types of relationships like one-to-one, one-to-many, and many-to-many are defined. An example entity relationship diagram is provided for a company database with employees, departments, and projects. Finally, it shows how to design tables from an entity relationship diagram by creating fields for each entity's attributes and adding foreign keys to represent relationships between tables.
The document provides an overview of data modeling and conceptual data modeling. It discusses key concepts in data modeling including entity relationship diagrams, attributes, domains, entity types, weak vs strong entities, and entity sets. It explains how data modeling follows analysis and documents business rules and policies to design a conceptual model of the database and relationships between data. The conceptual model is represented using an ERD.
ER diagram slides for datanase stujdy-1.pdfSadiaSharmin40
The document discusses database schema design using the entity-relationship (ER) model. It describes the database design process, which involves requirements analysis, conceptual design, and implementation including logical and physical design. The conceptual design phase develops a high-level description of the database using a technique like ER modeling. ER modeling represents entities, entity sets, attributes, relationships, and keys graphically. Relationships associate entities and define how they are related. The conceptual schema and functional requirements are then implemented through logical and physical database design.
The document discusses conceptual data modeling using the entity-relationship (ER) model. It begins by explaining how database designers interview users to understand data requirements and create a conceptual schema using a high-level ER model. This conceptual schema is then transformed into an implementation model using a commercial database system. The document also provides examples of an entity, attribute, relationship, and developing an ER diagram for a sample company database that tracks employees, departments, and projects.
The document discusses data modeling and the entity-relationship (ER) model. It defines key concepts like the ER model, entities, attributes, relationships and keys. The ER model is used to develop a conceptual design for a database through entity-relationship diagrams. These diagrams show entities, attributes and relationships. Entities can have primary keys, foreign keys and other types of keys to uniquely identify records. The ER model provides a high-level view of data that is later mapped to relational database schemas.
The document discusses the components of an Entity Relationship (ER) diagram including entities, attributes, and relationships. It provides examples of each component and their notations in an ER diagram. Specifically, it defines entities as objects or data components, attributes as properties of entities, and relationships as associations between entities. It also describes different types of attributes like key, composite, multivalued, and derived attributes.
Similar to Database - Entity Relationship Diagram (ERD) (20)
The document discusses the Abstract Factory pattern, which defines an interface for creating families of related objects without specifying their concrete classes. It provides advantages like isolating code from implementation classes and promoting consistency. The implementation overview describes creating shape and color interfaces and classes, an AbstractFactory interface, and Factory classes that extend AbstractFactory and create shape and color objects. FactoryProducer is used to get the appropriate factory. Tests create objects using the factories to demonstrate the pattern.
This document discusses the different types of joins in SQL, including inner joins, outer joins, and natural joins. Natural joins can be performed without using the JOIN keyword by listing tables separated by commas in the FROM clause and specifying the common column in the WHERE clause. There are 8 types of joins total, with inner joins being the most common way to combine row data from two tables through matching column values.
OOP - Understanding association, aggregation, composition and dependencyMudasir Qazi
In these slides i have tried to explains some confusing topics in object oriented programming like association, aggregation, composition and dependency. it's also a comparison oriented presentation.
In these slide i have tried to explains an interesting topic of programming, which is always a topic of discussion among programmers that is "variables and objects are passed-by-value or passed-by-reference in Java?" These slides will prove that Java is completely pass-by-value thing. There is nothing like pass-by-reference in Java.
In these slides i have explained an important design pattern that is "singleton pattern".
slides includes everything required about it, from definition to implementation and also different ways to achieve it according to situation and requirements.
in these slides i have explained the Observer design pattern. slides includes the complete definition, explanation and then implementation with code examples.
in these slides i have explained the difference between MVC, MVP and MVVM design patterns. slides includes definition, explanation and then implementation with code examples. it is a comparison oriented presentation.
in these slides i have explained the factory method design pattern. slides contains complete notes on this pattern from definition to implementation by code example.
Design Pattern - Chain of ResponsibilityMudasir Qazi
in these slides i have explained the Chain of Responsibility design pattern. slides includes definition, explanation and then implementation by code examples.
Modified O-RAN 5G Edge Reference Architecture using RNNijwmn
Paper Title
Modified O-RAN 5G Edge Reference Architecture using RNN
Authors
M.V.S Phani Narasimham1 and Y.V.S Sai Pragathi2, 1Wipro Technologies, India, 2Stanley College of Engineering & Technology for Women (Autonomous), India
Abstract
This paper explores the implementation of 6G/5G standards by network providers using cloud-native technologies such as Kubernetes. The primary focus is on proposing algorithms to improve the quality of user parameters for advanced networks like car as cloud and automated guided vehicle. The study involves a survey of AI algorithm modifications suggested by researchers to enhance the 5G and 6G core. Additionally, the paper introduces a modified edge architecture that seamlessly integrates the RNN technologies into O-RAN, aiming to provide end users with optimal performance experiences. The authors propose a selection of cutting-edge technologies to facilitate easy implementation of these modifications by developers.
Keywords
5G O-RAN, 5G-Core, AI Modelling, RNN, Tensor Flow, MEC Host, Edge Applications.
Volume URL: https://airccse.org/journal/jwmn_current24.html
Abstract URL: https://aircconline.com/abstract/ijwmn/v16n3/16324ijwmn01.html
Youtube URL: https://youtu.be/rIYGvf478Oc
Pdf URL: https://aircconline.com/ijwmn/V16N3/16324ijwmn01.pdf
#callforpapers #researchpapers #cfp #researchers #phdstudent #researchScholar #journalpaper #submission #journalsubmission #WBAN #requirements #tailoredtreatment #MACstrategy #enhancedefficiency #protrcal #computing #analysis #wirelessbodyareanetworks #wirelessnetworks
#adhocnetwork #VANETs #OLSRrouting #routing #MPR #nderesidualenergy #korea #cognitiveradionetworks #radionetworks #rendezvoussequence
Here's where you can reach us : ijwmn@airccse.org or ijwmn@aircconline.com
Vijay Engineering and Machinery Company (VEMC) is a leading company in the field of electromechanical engineering products and services, with over 70 years of experience.
internship project presentation for reference.pptxSaieJadhav1
Purpose :- Debian-based Linux distribution for advanced Penetration Testing and Security Auditing.- Developed by Offensive Security, known for security training.- Released in March 2013, a rebuild of BackTrack Linux following Debian standards.Maintained by Offensive Security:- Offensive Security oversees Kali Linux, ensuring it includes the latest security tools.- Known for certifications like OSCP (Offensive Security Certified Professional).Usage:- Penetration Testing: Simulates cyber-attacks to find system vulnerabilities.- Security Research: Helps researchers understand exploits and security techniques.- Computer Forensics: Used in digital crime investigations and data recovery.
Maintaining asset integrity, maximising performance, and reaching peak production outcomes all depend on effective defect elimination management.
The difficulties of locating, comprehending, and resolving asset flaws will be examined in this article, with a focus on the significance of having a complete awareness of their nature, implications, and possible outcomes.
The significance of maintenance departments creating a framework for integrating defect elimination and bad actor analysis into their proactive maintenance strategies, enabling them to make more informed decisions, becomes clear when we delve into the subtleties of defect analysis.
Defects in an asset are characterised as flaws, inadequacies, or departures from standard operating characteristics or design specifications.
The kind of defect, where it is located on the assembly of the asset, and what happens when it exists determine how one defect impacts the performance of the asset as a whole.
For example, a minor corrosion patch on a panel that is readily replaceable and does not pose a structural risk to the asset overall is unlikely to have an adverse effect on the asset's longevity, performance, or safety.
Effective Defect Elimination Management is critical for maintaining asset integrity, optimizing performance, and achieving peak production results. It involves identifying, understanding, and addressing asset defects systematically.
Understanding asset defects requires accurate identification and comprehensive documentation in the CMMS, including risk assessments that evaluate both the consequence and likelihood of defects leading to failures.
Defect Elimination Management (DEM) is a comprehensive approach that goes beyond traditional maintenance practices, focusing on root cause analysis and implementing long-term solutions to prevent defect recurrence.
"Bad Actors" in defect elimination refer to equipment, systems, or components that consistently underperform, require frequent maintenance, or cause repeated operational reliability or quality issues.
Advanced diagnostic tools and technologies, such as vibration analysis systems, infrared thermography, and AI-based analytics, have transformed the way asset defects are identified and managed.
Quality and timely repairs and clear business processes for managing defects are crucial, along with maintaining quality maintenance history data to provide valuable insights for future defect elimination processes.
To learn more, you can read my article via this link: https://www.cmmssuccess.com/defect-elimination-management/
,*$/?!~00971508021841^(سعر حبوب الإجهاض في دبيnafizanafzal
,*$/?!~00971508021841^(سعر حبوب الإجهاض في دبي)حبوب سايتوتك في ام القيوينالاجهاض للبيع في الامارات اسقاط الجنين بدبي حبوب الحمل للبيع # بيع؟ ؟ #شراء؟ ؟ #حبوب؟ ؟ #الاجهاض؟ #سايتوتك؟ #في؟ ؟ #دبي؟ ؟ #الشارقه؟ ؟ #عجمان؟ ؟ #العين؟ ؟ #ابوظبي؟ #الجنين؟ #سايتوتك؟ ؟ #للبيع؟ Cytotec # # الامارات # في؟ #دبي؟ # سايتوتك للبيع من داخل # دبي # شارقه # عجمان للطلب من باقي الدول في الخل #Data Opennesيتضمن قرار الإجهاض في عيادة الإجهاض في أبو ظبي ، الإمارات العربية المتحدة ، اعتبارات أخلاقية وأخلاقية ودينية وعائلية ومالية وصحية وعصر. شراء حبوب الإجهاض في دبي ، شراء حبوب الإجهاض في عمان ، شراء حبوب الإجهاض في أبو ظبي ، شراء حبوب الإجهاض في الشارقة ، شراء حبوب الإجهاض في رأس الخيمة ( RAK ), شراء حبوب الإجهاض في # عجمان ، شراء حبوب الإجهاض في العين ، شراء حبوب الإجهاض في أم القيوين حبوب الإجهاض الحصرية للبيع في دبي.
أين يمكنني شراء حبوب الإجهاض في دبي / الإمارات العربية المتحدة?
هل يمكنني الحصول على حبوب الإجهاض في دبي?
عيادة إجهاض النساء في الإمارات / دبي
أين يتم الإجهاض في الإمارات / دبي / أبو ظبي
عيادة الإجهاض الآمن في الإمارات / دبي / أبو ظبي.
أفضل عيادة إجهاض في الإمارات / دبي / قطر
حبوب الإجهاض عبر الإنترنت AMAZON / DUBAI / الإمارات العربية المتحدة.
حبوب الإجهاض في DISC HEM في دبي.
تكلفة حبوب الإجهاض في أبو ظبي / الإمارات.
حبوب الإجهاض بسعر الخصم الإمارات / دبي.
حبوب الإجهاض تظهر في دبي.
سعر حبوب الإجهاض في دبي.
حبوب الإجهاض في قطر.
حبوب الإجهاض آثار جانبية.
أنا حبوب الإجهاض في أبو ظبي.
أطقم أطقم غير مرغوب فيها في دبي / الإمارات العربية المتحدة
أطقم أطقم غير مرغوب فيها في أبو ظبي
أطقم أطقم غير مرغوب فيها في أجمان
أطقم أطقم غير مرغوب فيها في الكويت
أطقم أطقم غير مرغوب فيها في قطر / الدوحة
حبوب الإجهاض الإماراتية.
حبوب الإجهاض 1MG KUWAIT.
حبوب الإجهاض لمدة 12 أسبوعًا في دبي.
حبوب الإجهاض 24 ساعة في الإمارات / دبي.
حبوب الإجهاض بعد شهرين في هندي.
حبوب الإجهاض بعد شهرين في دبي.
حبوب الإجهاض تصل إلى 3 أشهر في دبي.
486 حبوب الإجهاض.
أفضل مجموعة في دبي / الإمارات.
حبوب الإجهاض 500.الإمارات العربية المتحدة
حبوب الإجهاض غير مرغوب فيها 72 دبي
In the global energy equation, the IT industry is not yet a major contributor to global warming, but it is increasingly significant. From an engineering standpoint we can achieve huge energy saving by replacing electronic signal processing with optical techniques for routing and switching, whilst longer fibre spans in the local loop offer further reductions. The mobile industry on the other hand has engineered 5G systems demanding ~10kW/tower due to signal processing and beam steering technologies. This sees some countries (i.e. China) closing cell sites at night to save money. So, what of 6G? The assumption that all surfaces can be smart signal regenerators with beam steering looks be a step too far and it may be time for a rethink!
On the extreme end of the scale we have AWS planning to colocate their latest AI data centre (at 1GW power consumption) along side two nuclear reactors because it needs 40% of their joint output. Google and Microsoft are following the AWS approach and reportedly in negotiation with nuclear plant owners. Needless to say that AI train ing sessions and usage have risen to dominate the top of the IT demand curve. At this time, there appears to be no limits to the projected energy demands of AI, but there is a further contender in this technology race, and that is the IoT. In order to satisfy the ecological demands of Industry 4.0/Society 5.0 we need to instrument and tag ‘Things’ by the Trillion, and not ~100 Billion as previously thought!
Now let’s see, Trillions of devices connected to the internet with 5G, 4G, WiFi, BlueTooth, LoRaWan et al using >100mW demands more power plants…
Future Networking v Energy Limits ICTON 2024 Bari Italy
Database - Entity Relationship Diagram (ERD)
1. Entity Relationship Diagram
A complete guide to design ER Diagrams
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 1
2. Contents / Agenda
• Definition
• Basic Components
• ERD Representations
• Chen’s Notation Symbols
• Crow’s foot Notation Symbols
• UML Notation Symbols
• Type of Entities
• Types of Attributes
• How to solve multivalued attributes
• Types of Relationships
• Implementation of 1:1
• Implementation of 1:M
• Implementation of M:M
• Connectivity and Cardinalities
• Summary
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 2
3. Definition
• The Relational Database Model (ERM-database containing tables)
forms on the basis of an ERD. The ERD represents the conceptual
database as viewed by the end user.
• ERDs depict the database’s main components: entities, attributes, and
relationships. Because an entity represents a real-world object, the
words entity and object are often used interchangeably. Thus, the
entities (objects) of the Tiny College database design (mostly discussed
in these slides) include students, classes, teachers and classrooms.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 3
4. Basic Components of ERD
• Entities:
• An entity is an object of interest to the end user. At the ER modeling level, an entity actually refers to the entity set and
not to a single entity occurrence. In other words, the word entity in the ERM corresponds to a table—not to a row—in
the relational environment. The ERM refers to a table row as an entity instance or entity occurrence.
• In both the Chen and Crow’s Foot notations, an entity is represented by a rectangle containing the entity’s name. The
entity name, a noun, is usually written in all capital letters.
• Attributes:
• Attributes are characteristics of entities. For example, the STUDENT entity includes, among many others, the attributes
STU_LNAME, STU_FNAME, and STU_INITIAL. In the original Chen notation, attributes are represented by ovals and are
connected to the entity rectangle with a line. Each oval contains the name of the attribute it represents.
• In the Crow’s Foot notation, the attributes are written in the attribute box below the entity rectangle. Because the Chen
representation is rather space-consuming, software vendors have adopted the Crow’s Foot style attribute display.
• Relationships:
• A relationship is an association between entities. The entities that participate in a relationship are also known as
participants, and each relationship is identified by a name that describes the relationship. The relationship name is an
active or passive verb; for example, a STUDENT takes a CLASS, a PROFESSOR teaches a CLASS and an AIRCRAFT is flown
by a CREW.
• Relationships between entities always operate in both directions. That is, to define the relationship between the entities
named CUSTOMER and INVOICE, you would specify that:
1. A CUSTOMER may generate many INVOICEs.
2. Each INVOICE is generated by one CUSTOMER.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 4
5. ERD Representations
• There are three main notations to represent and ERD
1. The Chen notation favors conceptual modeling.
2. The Crow’s Foot notation favors a more implementation-oriented approach.
3. The UML notation can be used for both conceptual and implementation
modeling.
• Because of its implementation emphasis, the Crow’s Foot notation can
represent only what could be implemented.
• We will also be using a new Short Hand notation that is easy to
understand and takes less place.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 5
8. UML Notation Symbols
Primary Keys are followed by [PK]
Foreign Keys are followed by [FK]
Relationships:
Cardinality 1 for ‘One’.
Cardinality * for ‘Many’.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 8
9. Advantages and Usage
• Advantages:
1. ERD tells us that how many tables you need and what would be the
relationship between them (you also have to do Normalization to know
finally how many tables would be in your database but still first step is ERD).
2. ERD is simple and understandable representation of a database. It helps a lot
to understand the whole database.
• Usage:
1. An ERD leads to ERM, means when ever you need to build a database with
tables, firstly, you need to create an ERD.
2. Crow’s foot notation is used most of all because its easy to understand in
implementation point of view.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 9
10. Types of Entities
• Existence Dependent
An entity is said to be existence-dependent if it can exist in the database
only when it is associated with another related entity occurrence. In
implementation terms, an entity is existence-dependent if it has a
mandatory foreign key—that is, a foreign key attribute that cannot be
null.
• Existence Independent.
If an entity can exist apart from one or more related entities, it is said to
be existence-independent (Sometimes designers refer to such an entity
as a strong or regular entity). Here foreign key attribute can be null.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 10
11. Types of Attributes (1)
• Required
A required attribute is an attribute that must have a value; in other words, it cannot be left
empty.
• Optional
An optional attribute is an attribute that does not require a value; therefore, it can be left empty.
• Domains
Attributes have a domain, a domain is the set of possible values for a given attribute. For
example, the domain for the grade point average (GPA) attribute is written (0,4) because the
lowest possible GPA value is 0 and the highest possible value is 4. The domain for the gender
attribute consists of only two possibilities: M or F (or some other equivalent code).
• Identifiers
The ERM uses identifiers, that is, one or more attributes that uniquely identify each entity
instance. In the relational model, such identifiers are mapped to primary keys (PKs) in tables.
There are Simple(Primary Key) and Composite (Composite Key) identifiers.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 11
12. Types of Attributes (2)
• Composite
A composite attribute, not to be confused with a composite key, is an attribute that can be further subdivided to yield
additional attributes. For example, the attribute ADDRESS can be subdivided into street, city, state, and zip code.
• Simple
A simple attribute is an attribute that cannot be subdivided. For example, age, sex, and marital status would be classified
as simple attributes.
• Single-Valued
A single-valued attribute is an attribute that can have only a single value. For example, a person can have only one Social
Security number, and a manufactured part can have only one serial number. Keep in mind that a single-valued attribute is
not necessarily a simple attribute. For instance, a part’s serial number, such as SE-08-02-189935, is single-valued, but it is
a composite attribute because it can be subdivided into the region in which the part was produced (SE), the plant within
that region (08), the shift within the plant (02), and the part number (189935).
• Multi-Valued
Multivalued attributes are attributes that can have many values. For instance, a person may have several college degrees,
and a household may have several different phones, each with its own number. Similarly, a car’s color may be subdivided
into many colors (that is, colors for the roof, body, and trim).
• Derived
A derived attribute is an attribute whose value is calculated (derived) from other attributes. The derived attribute need
not be physically stored within the database; instead, it can be derived by using an algorithm. For example, an
employee’s age, EMP_AGE, may be found by computing the integer value of the difference between the current date and
the EMP_DOB.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 12
13. How to Solve Multi-Valued attributes (1)
• Although the conceptual model can handle M:N relationships and
multivalued attributes, you should not implement them in the RDBMS.
Because in the relational table, each column/row intersection represents a
single data value. So if multivalued attributes exist, the designer must
decide on one of two possible courses of action:
1. Within the original entity, create several new attributes, one for each of the original
multivalued attribute’s components. For example, the CAR entity’s attribute
CAR_COLOR can be split to create the new attributes CAR_TOPCOLOR,
CAR_BODYCOLOR, and CAR_TRIMCOLOR, which are then assigned to the CAR entity.
(Not good).
2. Create a new entity composed of the original multivalued attribute’s components.
The new (independent) CAR_COLOR entity is then related to the original CAR entity
in a 1:M relationship. Note that such a change allows the designer to define color
for different sections of the car like top, body, interior etc. (Best solution).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 13
14. How to Solve Multi-Valued attributes (2)
Entity CAR contains a multivalued
attribute CAR_COLOR.
Solution 1: (Not good)
Solution to Multi-Valued attribute
by adding new attributes to CAR
entity.
Solution 2: (Best)
Solution to Multi-Valued attribute
by adding new entity with 1:M
relation to CAR entity.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 14
15. Relationships
• Ways of Classifying Relationships Types
A relationship type can be classified by the number of entity types involved, and by the degree of the
relationship type.
Following is a brief picture showing all types of relationships.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 15
16. Types of Relationships (1)
• One-to-One
• When both participants can have only one instance of each other. (less used but stable).
• For Example, HUSBAND can have only one WIFE and WIFE can have only one HUSBAND. This
is 1:1 relationship between HUSBAND and WIFE participants.
• One-to-Many
• When one participant can have multiple instances of other participants but other participant
can have only one instance of first participants. (mostly used and stable).
• For Example, CUSTOMER may generate many ORDERs but each ORDER is generated by one
CUSTOMER. This is 1:M relation between CUSTOMER and ORDER.
• Many-to-Many
• When both participants can have multiple instances of each other. (not practice).
• For Example, STUDENT can be enrolled in many SUBJECTs and one SUBJECT can be chosen
by many STUDENTs. This is M:M relation between STUDENT and SUBJECT.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 16
17. Types of Relationships (2)
• Weak relationship
Also known as a non-identifying relationship, exists if the PK of the related entity does not
contain a PK component of the parent entity. By default, relationships are established by having
the PK of the parent entity appear as an FK on the related entity (implemented in right picture).
• Strong relationship
Also known as an identifying relationship, exists when the PK of the related entity contains a PK
component of the parent entity (implemented in left picture).
• Recursive relationship
• A recursive relationship is one in which a relationship can exist between occurrences of the
same entity set (Naturally, such a condition is found within a unary relationship).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 17
18. Relationships (1:1) – Implementation (1)
• An example of a one-one relationship type is a person and his or her birth
certificate. We assume that everyone has one and that a certificate registers the
birth of one person only.
• Where there is a one-one relationship type we have the option of merging the
two entity types. The birth certificate attributes may be considered as attributes
of the person and placed in the person entity type. The birth certificate entity
type would then be removed.
• There are two reasons for not merging them:
1. The majority of processing involving PERSON records might not involve any or many of
the BIRTH_CERTIFICATE attributes. The BIRTH_CERTIFICATE attributes might only be
subject to very specific processes which are rarely executed.
2. the BIRTH_CERTIFICATE entity type has relationship types to other entity types that the
PERSON entity type does not have. The two entity types have different relationship types
to other entity types.
• Merging is not very harmful practically. so, its just a matter of choice which
implementation you want.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 18
19. Relationships (1:1) – Implementation (2)
• Following is implementations for 1:1 relationship.
One table has PK and other table must have same PK as well as FK.
Department Table has Department_ID as PK.
And Manager Table must have Department_ID as
PK as well as FK (You can change the name of
column but it should have same data).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 19
20. Relationships (1:M) - Implementation
• The common column is DEPARTMENT_ID (which is the primary key in
the DEPARTMENT table) should be as a foreign key in the EMPLOYEE
table. One individual DEPARTMENT_ID can relate to many rows in the
EMPLOYEE table.
Business Rule for this is:
“one department can relate to one or
many employees (or even no
employees) and that an employee is
associated with only one department
(or, in some cases, no department).”
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 20
21. Relationships (M:N) – Implementation (1)
• Consider the EMPLOYEE and PROJECT tables. The business rule is as follows:
One employee can be assigned to multiple projects, and one project can be
supported by multiple employees. Therefore, it is necessary to create an
M:M relationship to link these two tables.
• In the relational database we don’t implement the M:N relation by just
giving FKs to each other and the reason is we don’t want two sided links
(circles). So, we create a new entity called Bridge Entity and its PK is a
composite key made up with PKs of both tables. It may or may not have any
other attributes but composite key is must.
• After doing this, there becomes two 1:M relations.
1. One between Bridge and EMPLOYEE table (1:M).
2. One between Bridge and PROJECT table (1:M).
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 21
22. Relationships (M:N) – Implementation (2)
In this example we made Bridge Table
under name EMPLOYEE_PROJECT
containing PKs of both above tables. It
has one more attribute for some extra
information.
Now, it becomes like this and we have
three tables now.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 22
23. Removing Ternary and Hire order relations
• It is advantageous (but not necessary) to remove ternary and higher order relationship types. One
reason is that it might be considered more `natural' to think of entity types having attributes than
relationship types having them. It is in fact always possible to remove these high-order relationship
types and replace them with an entity type. A ternary relationship type is then replaced by an
entity type and three binary relationship types linking it to the entity types which were originally
linked by the ternary. A quaternary relationship type would be replaced by an entity type and four
relationship types and so on.
Ternary Relation Ternary Relation Solved into binary relations
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 23
24. Connectivity and Cardinalities
• Connectivity:
The term connectivity is used to describe the relationship classification. Just to show the relation
existence and type of relation between entities.
• Cardinalities:
Cardinality expresses the minimum and maximum number of entity occurrences associated with
one occurrence of the related entity. In the ERD, cardinality is indicated by placing the
appropriate numbers beside the entities, using the format (min , max).
1. Cardinality / mandatory:
maximum cardinality.
2. Modality / optional:
minimum cardinality or optionality.
Picture says, one PROFESSOR can teach one (min 1)
or more (max 4) CLASSes but each single (min 1)
CLASS can be taught by one (max 1) PROFESSOR at
time.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 24
25. Summary
• Following are main steps to create an ERD
1. Decide what are the entitles in your database.
2. Decide attributes for each entity.
3. Describe relationships between entities.
1. If there is any M:N relation, solve it into 1:M relationships.
• Note: ERD will not output a complete blue print to your database until
you do its Normalization. But, ERD + Normalization will give you
complete set of tables, attributes and relationships you need in your
database.
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 25