tartampion asked:
This is not a tutorial (there are good books and courses elsewhere), this is a workshop for DBAs and Developers who have an interest in modelling (Normalising) Relational Databases. Since you are asked me, you will get high performance, and a few 'built-in' standards as well.
[bxA]
In order for the discussion to move quickly, and for everyone to understand what is right and wrong, we need a standard against which to judge ourselves. The standards I apply (without defining them here), in the correct order, and each being a smaller sub-set (or stricter set of rules) within the preceding standard, are:
- Normalisation
- Relational Model (Codd's Twelve Rules)
- IDEF1X
I have done this a few times, so let us run this as a class. The value is in the interaction. I will put something up on the board; you post comments (questions and problems); I will update the board; etc. At any point in time, the Board consists of the following documents which will be kept up-to-date:
- Entity Relation Diagram
- Data Definition Language
(At this stage, a full Data Model does not seem necessary.)
Roles
I am the Modeller, you guys and dolls are the Developers, all working for the same college; we are working together on a new project to produce an Enrollment (and Schedule ?) system. As is usual these days:
- there is no formal systems analysis
- you deal with the users and gather requirements
- you identify app components, GUIs, reports ... and thus identify data requirements
- then we sit down in a workshop we work out the database
- as the project progresses, you identify additional or changed data requirements
- then we sit down in smaller workshops and work out the changes
It will start out loose, and get verified, tightened up, as we progress. I have no problem adding and changing, but I do not like deleting. Which is why I adhere to standards. The data columns and keys are the important part, so you need to supply them, and supply problematic items.
Alright, I have no idea what you need, so the Board is very much a first cut, with the first few obvious entities. I do not know much you know or don't know, you need to ask questions. Your turn.
I would like to ask you to explain the normalization steps in a simple case; for example "Student who have courses with different professors in different rooms of a college", please. We are the development DBAs, We all either understand the importance of normalization or try to understand it. You know it, so help us; give us a hint.Context
This is not a tutorial (there are good books and courses elsewhere), this is a workshop for DBAs and Developers who have an interest in modelling (Normalising) Relational Databases. Since you are asked me, you will get high performance, and a few 'built-in' standards as well.
[bxA]
In order for the discussion to move quickly, and for everyone to understand what is right and wrong, we need a standard against which to judge ourselves. The standards I apply (without defining them here), in the correct order, and each being a smaller sub-set (or stricter set of rules) within the preceding standard, are:
- Normalisation
- Relational Model (Codd's Twelve Rules)
- IDEF1X
I have done this a few times, so let us run this as a class. The value is in the interaction. I will put something up on the board; you post comments (questions and problems); I will update the board; etc. At any point in time, the Board consists of the following documents which will be kept up-to-date:
- Entity Relation Diagram
- Data Definition Language
(At this stage, a full Data Model does not seem necessary.)
Roles
I am the Modeller, you guys and dolls are the Developers, all working for the same college; we are working together on a new project to produce an Enrollment (and Schedule ?) system. As is usual these days:
- there is no formal systems analysis
- you deal with the users and gather requirements
- you identify app components, GUIs, reports ... and thus identify data requirements
- then we sit down in a workshop we work out the database
- as the project progresses, you identify additional or changed data requirements
- then we sit down in smaller workshops and work out the changes
It will start out loose, and get verified, tightened up, as we progress. I have no problem adding and changing, but I do not like deleting. Which is why I adhere to standards. The data columns and keys are the important part, so you need to supply them, and supply problematic items.
Alright, I have no idea what you need, so the Board is very much a first cut, with the first few obvious entities. I do not know much you know or don't know, you need to ask questions. Your turn.
No comments:
Post a Comment