Page 1 of 2 12 LastLast
Results 1 to 15 of 27
  1. #1
    Join Date
    Aug 2009
    Posts
    68

    Moving from "Should date Events..."

    So I repost the former question:
    Suppose we have a table like this:
    Medical_Exam
    ... PK, title, date and all that stuff
    Diagnostic_code String(10)
    Diagnostic_label String(256)
    ...

    and another one containing all diagnostic codes and labels.

    Diags
    ...
    Diagnostic_code String(10)
    Diagnostic_label String(256)
    ...

    When inserting or updating a row, application programs pick
    code and label choosen by the user in the second table and duplicate them to the columns of the first one.
    Is this structure normalized ?

    Quote Originally Posted by dportas
    If Diagnostic_code determines Diagnostic_label (my assumption based only on the names) then Medical_Exam is not in Boyce Codd Normal Form because Diagnostic_code is a non-key determinant (assuming it isn't a key of that table). Normalize it by removing Diagnostic_label from Medical_Exam.
    Diagnostic_code determines Diagnostic_label in the Diags table. In the Medical_Exam table, we know not.
    I try here to put only what one could see in the schema of a real database, so to speak, the formal data model.
    You can add a unique constraint on Diagnostic_code of Diag table if you use them.

    Do you think you can, only on this basis, tell if this is a correct design or a beginner's mistake ?

  2. #2
    Join Date
    Jul 2009
    Location
    Michigan
    Posts
    125
    There are only two situations where having Diagnostic_label in the Medical_Exam table is correct. The first is if the user is allowed to edit the Diagnostic_label. The second is if the Diagnostic_label in the Diags table changes periodically and you want the Medical_Exam table to store the Diagnostic_label as it existed at the time of the record creation. If neither of these situations apply then the Diagnostic_label shouldn't be stored in the Medical_Exam table.

  3. #3
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    Quote Originally Posted by Pyrophorus
    Diagnostic_code determines Diagnostic_label in the Diags table. In the Medical_Exam table, we know not.
    I try here to put only what one could see in the schema of a real database, so to speak, the formal data model.
    Normalization depends on the semantics of the data, not just the logical model. So it requires knowledge of the business domain outside the database - or at least a knowledge of the dependencies to be represented.

    However, it is a very strong convention (and one supported by ISO standards) that each data element should have a single unique and consistent name. On that basis alone it is suspicious to find Diagnostic_code and Diagnostic_Label in one table where code is a key and both again in another table where code is not a key. We ought at least to suspect a non-key dependency in that case.

  4. #4
    Join Date
    Aug 2009
    Posts
    68
    Quote Originally Posted by MarkATrombley
    There are only two situations where having Diagnostic_label in the Medical_Exam table is correct. The first is if the user is allowed to edit the Diagnostic_label. The second is if the Diagnostic_label in the Diags table changes periodically and you want the Medical_Exam table to store the Diagnostic_label as it existed at the time of the record creation. If neither of these situations apply then the Diagnostic_label shouldn't be stored in the Medical_Exam table.
    It's exactly how I would have replied.

    But this example is only an illustration of a more general situation.

    You say normalization needs data semantics and not only the formal model. This means the relationnal model is not self-consistent, or in other words, it can't stand alone. More of it, there is a purely formal solution to the problem: identity. Here, the problem is to know if we have a single piece of data or clones. The relationnal model cannot take this in account (but others does) and you have to add assumptions or use conventions.

    This doesn't means I think the relationnal model is bad. IMO, it' like programming in assembly language: looking at some piece of code, no one can tell exactly what's going on. Well, this zeroes a block of memory, but are we initializing some mysterious data structure or crushing the stack and leading the system to an horrible death ?
    I spent ten years of my life programming with assemblers and I do loved it. But I moved to others things. Sometimes, I look with atonishement to the enormous size of todays applications and systems and think 90% of it are most probably pure waste of memory and CPU time. But I would not turn back.

    IMHO, we wouldn't have to deal with the relationnal model as we have not to deal with stacks, registers and so on, because both are too low level. And we should build something on it, modelling the semantics RM can't take in account.
    Best regards.

  5. #5
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    Is this structure normalized ?
    No. If DiagnosticCode is the Diagnostic PK; and DiagnosticCode: DiagnosticLabel is 1:1, then MedicalExam.DiagnosticLabel is a blatant duplicate. MedicalExam.DiagnosticCode remains as a FK.
    When inserting or updating a row, application programs pick code and label chosen by the user in the second table and duplicate them ...
    Any form of data duplication is a bright red flag that Normalisation has not been performed to completion; the first and stated goal is elimination of duplication. And anyone who has had to work with keeping duplicates up-to-date will know why. Ok, maybe not here.

    Do you think you can, only on this basis, tell if this is a correct design or a beginner's mistake ?
    I wouldn't call it "beginner's mistake" but it is a classic and common mistake, and for the following common reason:
    There are only two situations where having Diagnostic_label in the Medical_Exam table is correct. The first is if the user is allowed to edit the Diagnostic_label. The second is if the Diagnostic_label in the Diags table changes periodically and you want the Medical_Exam table to store the Diagnostic_label as it existed at the time of the record creation. If neither of these situations apply then the Diagnostic_label shouldn't be stored in the Medical_Exam table.
    That is the two justifications for the mistake, it remains a mistake.

    1 The correct method to handle 'user allowed to edit the DiagnosticLabel' is: allow the user to edit the Diagnostic table. The assumption is that MedicalExam sometimes has "private" or user-entered Diagnotic Labels. If there are a set of diagnostic labels that are constitute a "master" set; that the user cannot edit, fine, add a column IsMaster or IsUser, etc, and allow the insertion of user Diagnostic Labels, before inserting MedicalExam, in a transaction.

    2 Well, given that it is a database, with Referential Integrity, one cannot change the value of Diagnotic.Label if it is relied upon for historic purposes (you cannot change history after the fact of it). There will be decisions to make, such as, once a Diagnostic row is referenced from MedicalExam, it cannot be edited. It is a simple issue to add a column IsObsolete; when populating the drop-down box containing Diagnostic.Labels, simply choose where IsObsolete = 0. When the Diagnostic Label needs to be "changed"; simply set IsObsolete = 1 on the old row, and insert a new row (hopefully in a transaction). No cascades, nothing. New MedicalExams get the new Diagnostic rows; existing MedicalExams remain unchanged (the fact in the past remains the fact).

    This preserves the value as it was when the MedicalExam was inserted.
    You [dportas] say normalization needs data semantics and not only the formal model. This means the relationnal model is not self-consistent, or in other words, it can't stand alone.
    I respect dportas, but here I disagree. Data semantics are important, and should be considered; but no, the data model is independent, and consistent in and of itself. The RM stands alone. It can have many apps sitting on top of it but it stand alone.

    Sometimes, I look with astonishment to the enormous size of todays applications and systems and think 90% of it are most probably pure waste of memory and CPU time.
    I am with you completely. You should see some of the massively duplicated filing systems, poured into containers labelled "database", that provide none of the "database" capabilities, that get passed off as "databases". We put men on the Moon using 8-bit systems; 40 years later we cannot even load the next release of Windoze, we have to buy a new computer. Hilarious and sad at the same time. Mediocrity is now the norm.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  6. #6
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    Quote Originally Posted by Pyrophorus
    You say normalization needs data semantics and not only the formal model. This means the relationnal model is not self-consistent, or in other words, it can't stand alone.
    That doesn't follow at all. The relational model does its job perfectly well as does any consistent mathematical model. The RM does not depend on the semantics any more than arithmetic or calculus does.

    However, to make the mathematics more useful in practice we use tools such as Normalization which are about validating a relation schema in the context of some semantic rules (functional and join dependencies). Normalization is an interpretation that we apply on top of a relation schema. Certainly the relation schema is still capable of standing alone without that interpretation. The concepts of Normalization are just one optional but very useful application of the model.

  7. #7
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    dportas

    1 Now you are making further distinctions, re what you posted before; separating the relational algebra, the RM, Normalisation. I agree with that.

    2 But for the purpose of Pyrophorus' question, those distinctions may not be necessary. As I understand it, he is asking about the independence of the Normalised or Relational model, from the semantics, which are required when the logical implemented as the physical.

    3 I agree completely that Normalisation is independent of the RM. I can assure you from years of personal experience, that we were performing formal and systematic Normalisation on databases long before the Relational model was available. Normalisation is often assumed in the RM. But if I were to be exact (make distinctions at the level such as yours), I would state:
    • the database is not a Database unless it is Normalised (one can produce a perfectly good, Normalised, non-relational Database).
    • the database is not a Relational Database, unless it faithfully implements the Relational Model (and thus one can perform relational functions on it)
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  8. #8
    Join Date
    Aug 2009
    Posts
    68
    Quote Originally Posted by Derek Asirvadem
    1 The correct method to handle 'user allowed to edit the DiagnosticLabel' is: allow the user to edit the Diagnostic table. The assumption is that MedicalExam sometimes has "private" or user-entered Diagnotic Labels. If there are a set of diagnostic labels that are constitute a "master" set; that the user cannot edit, fine, add a column IsMaster or IsUser, etc, and allow the insertion of user Diagnostic Labels, before inserting MedicalExam, in a transaction.
    First, your "correct" solution works not because the unique constraint on Diagnostic_Codes in Diags table. Don't tell me, it's bad design and we could change it. It can be a business rule and we have to model reality, not twisting things to fit our design.
    Second, the diags table will gather a large collection of mispelled labels. The isUser flag can prevent users to see all this crap, but cleaning this table by hand would prove to be a taedious job. (Passing by, I would say these quasi-duplicate are to me a far more serious problem than strict duplicates. I can easily create a task to get rid of strict duplicates or set up a constraint to avoid them. Quasi duplicates (like mispelled labels) are much more difficult to manage, but spoil the data exactly in the same way).
    Quote Originally Posted by Derek Asirvadem
    2 Well, given that it is a database, with Referential Integrity, one cannot change the value of Diagnotic.Label if it is relied upon for historic purposes (you cannot change history after the fact of it). There will be decisions to make, such as, once a Diagnostic row is referenced from MedicalExam, it cannot be edited. It is a simple issue to add a column IsObsolete; when populating the drop-down box containing Diagnostic.Labels, simply choose where IsObsolete = 0. When the Diagnostic Label needs to be "changed"; simply set IsObsolete = 1 on the old row, and insert a new row (hopefully in a transaction). No cascades, nothing. New MedicalExams get the new Diagnostic rows; existing MedicalExams remain unchanged (the fact in the past remains the fact).
    We manage this particular problem otherwise: each row has a start and end validity date. In that way, if someone is editing an exam, we can provide her/him the list of valid diags at the exam date (and not today valid diags, which would be inconsistent).

    By the way, I think what Mark stated about storing the state of an exam is exact. These exams are legal documents, so we have to prove they remain "as they are" after some validating decision (printing most often). I can do that easily if all state is packed in one row of one table (moving it to a read only tablespace, or creating a trigger updating a modification date on every update). Doing the same on a state splitted over many tables and shared with other documents seams to me (at least) rather complex to manage.

    This illustrates perfectly my point. You ran into normalization assuming data looking the same are actually the same. But if they are not, you run into problems. IMO, there's nothing wrong with normalization or relationnal model, but one must not rely only on this to design data models. There are subtle points like identity which can remain unseen and this can lead to undesired behavior or useless complexity.

    Regards,

  9. #9
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    First, your "correct" solution works not because the unique constraint on Diagnostic_Codes in Diags table. Don't tell me, it's bad design and we could change it.
    Not sure what you mean there ... You can have one or more of: Unique on (DiagnosticCode), (DiagnosticCode, IsMaster), (IsMaster,DiagnosticCode) ... it depends on the exact rules you wish to implement in your model.

    We are discussing theory and the correct practice of theory here. I was not providing one Final Solution that works in all situations; I was correcting a single element of incorrect practice, a I used the example already provided. It is up to you to understand it and implement your rules, what you can, based on your project constraints.
    It can be a business rule and we have to model reality, not twisting things to fit our design.
    Yes, absolutely, that is the whole point. My recommended Diagnostic table models the reality being discussed, not the other way around (and certainly only the example being discussed) and uses the example already provided:
    users can or cannot edit the Diagnostic table
    if they can: there is a IsMaster list which only users_privileged_to_modify_Diagnostic can edit; and the rest, which only users_privileged_to_insert_Diagnostic can edit
    security and permissions are ordinary and simple to set up, that is a separate issue to the thread, tangential
    Second, the diags table will gather a large collection of mispelled labels. The isUser flag can prevent users to see all this crap, but cleaning this table by hand would prove to be a taedious job.
    Depends. Obviously the spelling of both IsMaster and Not IsMaster Diagnostic.Labels is going to be only as good as the language skills of the people who enter the lists. It is no big deal to:
    always produce the IsMaster list for the user to choose from
    allow entry (IsMaster = 0) only if the user cannot find the Label on the IsMaster list
    check that the attempted new Label is not close to an existing, IsMaster Label (most commercial RDBMS have good string search and soundex functions), and disallow it.

    Data Quality (as opposed to Refential Integrity or Data Integrity) which is the new point being discussed here, is controlled by the app and the structures you implement in the db. Very little programmatic checking results in masses of bad data (including typing errors); good checking results in less bad data. It simply depends on how much effort you put into it. Once the bad data is in the database (it was entered by hand), yes, the user has to clean it by hand. Garbage in, garbage out. Better to prevent it, rather than allow it, and then have to clean it up.

    Here's one of several methods, each has their capabilities. For a similar requirement (to Diagnostic discussed here), in one assignment where over time, they had entered masses of Not IsMaster rubbish, and 80% were near-duplicates of IsMaster list, I cleaned it up using pure SQL, soundex, after ignoring vowels. Note I was doing a db rebuild not a data cleanup, the problem I was responding to was, the table was 400% larger than planned; Not IsMaster was supposed to be maximum 10% of IsMaster, not 400%.

    Here's another method. I have done this for medical Dosage table, Survey Question, as well as hardware Part Description:
    Implement a Keyword Table (one single correct spelling, capitalisation, known acronyms; all terms used); Keyword consists of a keyword plus a placeholder for an optional numeral
    very few, and only application-knowledgeable people (doctors, pharmacists, store inventory managers) have permission to insert Keyword
    When the user creates a new Diagnostic.Label, isMaster or Not, they construct the Label string from the content of the Keyword table only (drop-down; alphabetic search; select)
    Supply a numeral if there is a placeholder for it
    (Passing by, I would say these quasi-duplicate are to me a far more serious problem than strict duplicates. I can easily create a task to get rid of strict duplicates or set up a constraint to avoid them. Quasi duplicates (like mispelled labels) are much more difficult to manage, but spoil the data exactly in the same way).
    Agreed, you need a structure (tables plus code) to prevent or reduce that. Select from IsMaster list first; use soundex; implement security, as detailed above. Plus whatever your extensions you need (this is not the Final Solution).
    We manage this particular problem otherwise: each row has a start and end validity date. In that way, if someone is editing an exam, we can provide her/him the list of valid diags at the exam date (and not today valid diags, which would be inconsistent).
    No problem from me, as long as it is Normalised, which is what we are discussing here.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  10. #10
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    By the way, I think what Mark stated about storing the state of an exam is exact. These exams are legal documents, so we have to prove they remain "as they are" after some validating decision (printing most often). I can do that easily if all state is packed in one row of one table (moving it to a read only tablespace, or creating a trigger updating a modification date on every update).
    (We are getting off the topic, and getting into special cases.) Again I did not provide a Final Solution, we are discussing theory and practice. It gets tangential when we jump tracks and start discussing another subject; we lose sight of the original point. Whether you need a carbon copy or a read-only copy of a legal document is quite separate to the theory and practice of Normalisation. If you need it, by all means, go ahead and create your read-only copy in any way you see fit; audit tables and true read-only copies of row-level changes or legal documents are an ordinary and common element of commercial databases; whether the online, read/write tables are Nomarlised or not is a separate issue. Justifying the avoidance of Normalisation on the basis of the need for read-only copies of legal documents does not hold water. That is like justifying the avoidance of Normalisation based on the fact that most users view the data in grids, in spreadsheets (and thus you can implement spreadsheets in the db).

    Normalisation eliminates duplicate data, and provides speed; many small tables rather than fewer larger tables. The example discussed has and allows duplicates which can easily be eliminated; that, and not the the read-only copies, is the point.
    Doing the same on a state splitted over many tables and shared with other documents seams to me (at least) rather complex to manage.
    I suppose that depends on your experience and the tools you use. It is 2009. Hopefully you are using a GUI tool, and not executing character-level commands to the RDBMS. I do all my DDL changes and SQL scripting from a single tool; many databases, many customers, about 1000 objects. When I am using a development team and cutting a release, we use a project-level code version management tool. The more objects you have, the more you need good naming standards and Normalisation at the code level as well (to eliminate duplication).
    This illustrates perfectly my point. You ran into normalization assuming data looking the same are actually the same. But if they are not, you run into problems.
    No, you cater for that. Normalisation does not take away or absolve you of the design and construction responsibilities you have; it is one serious tool in your toolkit. And if it does not appear to work, or provide the final solution, it does not mean that Normalisation is broken; it means that you have not practiced it faithfully. That is the essence of the thread, providing a better understanding of that one component.
    IMO, there's nothing wrong with normalization or relationnal model, but one must not rely only on this to design data models. There are subtle points like identity which can remain unseen and this can lead to undesired behavior or useless complexity.
    Again, that is two separate points. Normalisation and the RM relate to the data model, it does not promise all things to all people; if done correctly, subtle unseen and undesired behaviour within the database is eliminated. There is no suggestion that Normalisation can affect the subtle, unseen and undesired behaviour of the app or anything outside the data model.

    There are distinctions between the following:
    a. A data model that has been correctly Normalised (separate to the app components rquired to provide a complete application)
    b. A data model that has been incorrectly Normalised
    c. A data model that has not been Normalised
    For the data model to be stable (correct, therefore you do not have to re-implement) and easily extensible (you do not have to re-code when you add elements), there is no method that exists except (a). (b) and (c) virtually guarantees re-coding, when either the app or the database changes.

    Now for the app and everything outside the data model.
    i. If the DM is in state (a), and just as standards have been implemented in the DM, standards are implemented in the app, the result will be no subtle, unseen and undesired behaviour overall.
    ii. If the DM is in state (a), and no standards are implemented in the app, the result will be many subtle, unseen and undesired behaviour overall; more on the app behaviour side and less on the data side.
    iii. If the DM is not in state (a), and no standards are implemented in the app, the result will be a veritable collection of subtle, unseen and undesired behaviour overall; the app behaviour side and the data side squared.

    In summary
    we are discussing data models, and Normalisation is the only available method of producing a quality, stable and extensible DM
    there are many other considerations and areas in any project, these do not have any bearing on whether the DM should be Normalised correctly
    using considerations of any one area to avoid correct, standard-compliant implementation in another, will produce a worse product overall (high cost, high maintenance, low performance)
    it is much better (cost, labour, problems) to design and produce the component in each area to standards and to the best of your ability.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  11. #11
    Join Date
    Jul 2009
    Location
    Michigan
    Posts
    125
    I have been staying out of this since my original post, but I guess I will jump back in to clarify my answer and respond to some of the criticism to it.

    The original question was "Do you think you can, only on this basis, tell if this is a correct design or a beginner's mistake ?"

    My answer stated the only two real-world cases I know of where that design is correct. Without knowing the requirements for a database design it is impossible to know if it is correctly designed or not. In the real world you are paid for results and if the requirements (and business rules) call for denormalization then the correct design is a denormalized design.

  12. #12
    Join Date
    Aug 2009
    Posts
    68
    Quote Originally Posted by Derek Asirvadem
    Quote Originally Posted by Pyrophorus
    First, your "correct" solution works not because the unique constraint on Diagnostic_Codes in Diags table. Don't tell me, it's bad design and we could change it.
    Not sure what you mean there ... You can have one or more of: unique on (DiagnosticCode), (DiagnosticCode, IsMaster), (IsMaster,DiagnosticCode) ... it depends on the exact rules you wish to implement in your model.
    I meant only there *IS* a unique constraint on Diagnostic_Code and no I *can* or *may* or *could have* it or some others things. Since you can't insert rows sharing the same Diagnostic_Code, the solution you gave works not even if it works perfectly in other cases where the constraint exists not. Is that clear enough ?

    Quote Originally Posted by Derek Asirvadem
    (We are getting off the topic, and getting into special cases.) Again I did not provide a Final Solution, we are discussing theory and practice. It gets tangential when we jump tracks and start discussing another subject; we lose sight of the original point.
    Exact, but which was the original point ? You summarized it in *your* way, saying the problem was:
    Quote Originally Posted by Derek Asirvadem
    users can or cannot edit the Diagnostic table
    if they can: there is a IsMaster list which only users_privileged_to_modify_Diagnostic can edit; and the rest, which only users_privileged_to_insert_Diagnostic can edit.
    You should read again the original post: it has nothing to do with editing the Diagnostics table and nothing about "how to edit the Diagnostic table" nor with isMaster feature. You are turning the example to something else, familiar to you, escaping the original question and starting to explain things probably well known to most readers (including me) as if we were base ignorants.

    I think you understand not what I'm doing here: I'm exploring for my own profit the validity limits of the model, like physicists does. This means not the model is wrong, but it can't apply in all situations (as all models, by the way). Limit situations obviously ! And that's precisely why getting in special cases is not tangential but the heart of my question.
    Mark and Daniel replied clearly they could not tell with so few elements, and it's perfectly satisfactory to me because I didn't asked how to build a custom dictionnary or a domain, and I thank them to give me their opinion.
    You said "no, absolutely no" and it would be valuable to me if you could prove this statement, so to speak, produce a normalized model which manage equally both situations: carbon-copy and domain in a general way. Instead, you replied explaining how to set up a particular solution which in the example I gave, works not.
    Sorry but I don't buy this.

    @Mark:
    I would be very interested if you could elaborate your point, particularly on which basis you decide to adopt denormalized models ?

  13. #13
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    Quote Originally Posted by Pyrophorus
    @Mark:
    I would be very interested if you could elaborate your point, particularly on which basis you decide to adopt denormalized models ?
    I also. How can a business rule call for a denormalized design? The point of a normalized design is precisely that it implements some set of business rules (dependencies). Denormalization means adding further dependencies to that model which are by definition redundant. Unless you are talking about a requirement to implement the model in some particular (and unnamed) DBMS - but that's nothing to do with "business rules" as most people will understand the term.

  14. #14
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    I'm comfortable with @Mark's second scenario, and I am comfortable that (in that scenario) the database is still normalised. I don't understand why it is not considered normalised. Removing duplicated data is not a goal of normalisation, it is a consequence of it. The goal of normalistion is to eliminate the possibility of update anomolies. It just so happens that the consequence of achieving this goal involves removing duplicated data.

    The point of Mark's second scenario is that although on creation the data is "duplicated", it is the value not the attribute that occurs in both tables. One is an attribute of the diags table, the other an attribute of the medical exam. They are both wholly dependent on the key. Although Derek's solution is more efficient and elegant (although I would use an effective_from_date rather than a bit, bit this is fairly minor), I don't believe it normalises an otherwise unormalised design.

    I think I'm echoing David here, in so far as the design may or may not be normalised depending on the business rules.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  15. #15
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    BTW - just to add as well that I too strongly suspect that this is not normalised, just that there is not sufficient information to state with 100% certainty that it is.
    Testimonial:
    pootle flump
    ur codings are working excelent.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •