Introduction to Database Design with Entity Relationship Diagrams
•Transferir como PPTX, PDF•
6 gostaram•2,790 visualizações
This presentation was delivered to the Silicon Valley Code Camp in a session entitled "Introduction to Database Design with Entity Relationship Diagrams" on October 9, 2011. The intent of the presentation is to teach people how to understand, create and work with ER diagrams. There are also a number of topics introduced for the purpose of stimulating self-directed learning after the presentation. The presentation featured a demo where the audience participated in the design and normalization of a database in real time.
Recomendados
Mais conteúdo relacionado
Semelhante a Introduction to Database Design with Entity Relationship Diagrams
Semelhante a Introduction to Database Design with Entity Relationship Diagrams (20)
Último
Último (20)
Introduction to Database Design with Entity Relationship Diagrams
- 1. Yes! Database Design can be this fun Mark Abramson, CEO, Forward Thought, Inc. 10/9/2011 © 2011 Mark Abramson / #svcc 1 @mark__a
- 2. THEORY & ELEMENTS DEMO Q&A 10/9/2011 © 2011 Mark Abramson / #svcc 2 Edgar F Codd
- 3. Microsoft BizSpark Startup Partner Organizer of BizSparkSFMeetup Group Regular customer of all tools used in demo Schema-first kind of guy 10/9/2011 © 2011 Mark Abramson / #svcc 3 Disclosures
- 4. What is a database design? 10/9/2011 © 2011 Mark Abramson / #svcc 4
- 5. Why Database Design? Gives everyone a clear picture of your business rules and the data behind it Build consensus across business units Separation of concerns Ensure data accuracy Fun 10/9/2011 © 2011 Mark Abramson / #svcc 5
- 6. Entity / Relationship Model An Entity is some “thing” of interest A Relationship defines the interaction between one or more Entities 10/9/2011 © 2011 Mark Abramson / #svcc 6
- 7. What’s the data look like? 10/9/2011 © 2011 Mark Abramson / #svcc 7
- 8. Entity Definition Attributes Data Types NULL option Primary Key Foreign Key Identity Columns 10/9/2011 © 2011 Mark Abramson / #svcc 8
- 9. Relationship Definition Identifying Non-Identifying 10/9/2011 © 2011 Mark Abramson / #svcc 9 Non-Identifying Relationship
- 10. Relationship (2) Recursive references Associative / Many-To-Many /“Join Tables” 10/9/2011 © 2011 Mark Abramson / #svcc 10
- 11. Cardinality How many instances of each entity may be involved or must be involved? 10/9/2011 © 2011 Mark Abramson / #svcc 11
- 12. Keys Primary Keys Foreign Keys Candidate Keys Composite Keys 10/9/2011 © 2011 Mark Abramson / #svcc 12
- 13. Normalization 10/9/2011 © 2011 Mark Abramson / #svcc 13 Denormalization Normalization
- 14. Getting Fancy First, second, third-normal form Generalization Nonspecific relations Three-way relationships Constraints Referential Integrity actions Zachman’s Framework 10/9/2011 © 2011 Mark Abramson / #svcc 14
- 15. Exercise! Legacy Baggage 10/9/2011 © 2011 Mark Abramson / #svcc 15
- 16. Tools for Creating Your Model Paper + Pen / Whiteboard Drawing Tools: PowerPoint, Visio ER Tools: Open Source / Community Editions CA ERWin; Toad; SSMS; MySQL Workbench ER Tools: Midrange Sparx Systems EA $199; Toad $479 ER Tools: High End CA ERWin $4000; Embarcadero $2000 10/9/2011 © 2011 Mark Abramson / #svcc 16
- 17. Demo time! SQL Server Management Studio (“free”) http://www.microsoft.com/download/en/details.aspx?id=7593 RedGate SQL Data Generator ($295) http://www.red-gate.com/products/sql-development/sql-data-generator/ RedGate SQL Prompt Pro ($295) http://www.red-gate.com/products/sql-development/sql-prompt/ 10/9/2011 © 2011 Mark Abramson / #svcc 17
- 18. Resources 10/9/2011 © 2011 Mark Abramson / #svcc 18 Designing Quality Databases With Idef1X Information Models Thomas A., M.D. Bruce $3.91 on Amazon! SQL in a Nutshell: A Desktop Quick Reference Kevin Kline, Brand Hunt, Daniel Kline $18 on Amazon The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises Len Silverston $45 (also check out Vol. 2 and Vol. 3) http://www.databaseanswers.org/data_models Repository of simple examples of db models Free! http://publib.boulder.ibm.com/infocenter/wchelp/v5r6/index.jsp?topic=/com.ibm.commerce.data.doc/refs/rdmindex.htm IBM WebSphere data model Also search for ER Diagrams for other large systems to see how someone else addressed a set of entities and relationships (MS Dynamics, SAP, etc.) Image Credits Slide 1: flickr/besser.jetzt Slide 2: IBM Slide 3: flickr/Pete Reed Slide 4: flickr/Artful Magpie Slide 14: Amazon.com Slide 15: flickr/Jon Ashcroft All ER diagrams: Mark Abramson www.StackOverflow.com
- 19. 10/9/2011 © 2011 Mark Abramson / #svcc 19 SV Code Camp Peter Kellner Edgar Codd Attendees Loving Wife Thomas Bruce Mom + Dad
Notas do Editor
- 25-30 minutes of instruction, 15-20 minutes of demo, 30+ minutes of Q&AI hope I’ll address most of your questions, so write them down + let’s talk about them at the end of the slidesBut if you don’t understand something, please interruptFirst off, I’d like to see where you’re at – where are you with your understanding and experience w/modeling?Comfy with SQL? Write a join query? Have done modeling before? Dealing with someone else’s mess
- Edgar F.Codd – British IBM researcher, regarded as the inventor of the relational model for database managementGOALS FOR SESSION: At the end of this session, you should be able to read, understand and create database Entity Relationship diagramsThere will be a couple of exercises for the audience as we go and an Interactive demoQ&A – very curious about what you’re facing out there in the world
- Want you to know of any bias that may affect my talkCheck out November 7thMeetup all about Tools, Tools and More Toolswww.bizsparksf.com
- Visual representation of the ENTITIES and RELATIONSHIPS between themBased on rules from the real world / your business; Entails a number of rules, standards and guidelinesGreat way to communicate with co-workers, customers, developers; Great working model and critical reference documentYou could consider this as a whole bunch of linked-together Excel worksheets: these fields define the columnsWorking with a model is 50% science, 50% art, 50% experience
- C’mon, you have to put all that data *somewhere*!Fun? YES! It’s a great mental exercise that forces you to think through a lot of hard problemsSeparation of Concerns (1974, check Wikipedia)
- Entity = object that is important to the business.Entity = the NOUNRelationship = how are these objects/entities relating to one another?Relationship = the VERB; the VERB PHRASE
- CustomerId in SalesOrder table references a record/row in the Customer tableWe can look up / refer to related or seemingly unrelated data elsewhere
- What’s in a name?Naming conventions – singular vs. plural DESCRIBE THE BUSINESSAttribute = property of an Entity = Columns of database tableData type choice (decimal vs. float vs. money) varchar vs. nvarchar vs. char vs. textNULL option – is this attribute mandatory or required per business rules?Primary Key: unique identifier for each row of dataForeign Key: some other entity’s primary key that appears here due to some relationship between the twoIDENTITY column: guarantees uniqueness and auto-increments (autonumber). (1,1) specifies the SEED and INCREMENT
- Not just a Facebook statusA relationship is the “verb” between entities – defines how they interact per business rulesNaming / “writing a sentence”Defines how the entities interactRead the relationship from parent->child (end with the dot)Identifying: the child is dependent on its parent for its identityNon-identifying: may be existence dependent but not identity dependent
- Sometimes we end up with odd relationships and don’t know whyAssociative / link / join / junction table: used for many-to-many tablesCan make joins a little more difficult but is a common patternGREAT for when you want to use an entity in other areas, e.g. Customer<->Address and Person<->Address
- Cardinality: how many instances of each entity may be involved or must be involved?w/ identifying – there has to be one Customer for some # of Addressw/ non-identifying – no requirement to have a Customer to have an Address (could be an Employee Address, Order Address, etc.)<nothing> One-to-zero-or-more:<P> one to one or more<Z> one to zero or one<N> one to exactly Nw/ non-identifying relationships, these can all be zero-or-one-to…
- Primary Key – unique identifying key (can be any data type as long as it’s unique)Foreign Key – some other entity’s PK that appears here because of some relationship with itCandidate Key – Could this work as a PK? What’s are the candidate keys in this table?Composite Key – put a few fields together to get a unique keyStrings? Timestamps? Integers? Decimals?
- DENORMALIZED:Data can be duplicated and get out of syncEase of queryingPerformance considerationsNORMALIZED:One “fact” occurs in one place and only one placeRequires you to get the business rules “right”No way to have data concurrency issuesDoes require a lot of joins
- Great opportunities for self-directed learningCascading deletes
- In some ways it’s easier to create than repair… let’s work together to see how we can improve this modelFirstName/LastName fields long enough?StateProvince field?Website (255) OK?Are all of these fields really OK to be nulls?WTF is OwnerId doing in Country? State?Is StateCode and CountryCode OK for a PK? Why not a bigint?Relationships in wrong directionDenormalizedInfo? What is this? A flag?
- Features + benefits of these as you go up/down the food chain