Requirments for ERD Module, Review page

Created on 28.06.07 04:39:28 by Wessam Abdrabo

This page is used to manage the review of the second revision of the requirements spec for the ERD module.

The value of this approach is that it allows us to track each issue separately and drive them to resolution. The document can be considered approved when all comments are marked as Approved.

The review process works like this:

  • Add a comment header of the format
    "<initials>-<number> - <description> (<status>)"
    (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved. If a comment has no status, it is assumed to be unresolved.
  • If necessary, we do more rounds of discussion until the item is marked as Approved
  • There may be some items which can not be resolved through this means. If that happens, we may arrange a meeting (perhaps on an IRC channel) to try and work through the remaining open issues.

Commenter Initials Key


DVC1 - Overall - Approved

Wow, a very focused, simple, document. This is very good, it helps us stay very focused.

Thanks David for the great review. Comments are answered bellow. Those that are not are already taken care of -Wessam

DVC2 - Core Requirements - Approved

I would suggest renaming "deploy database" to "build database", as deploy has a specific meaning that is more associated with deploying applications to a web server or app server

DVC3 - Core Requirements - Approved

Isn't graphically designing ER components (item 6) and editing an E/R diagram (item 5) the same thing?

DVC4 - ER components - Approved

I think a recursive relation is pretty key, and would rate this a P1. The goal here is to be able to model the majority of database schemas out there, and a recursive relationship seems pretty common

Why does this require a special notation? It's just a standard case of a 1:M relationship, except both ends are bound to the same entity. I actually don't see these too often in practice, although they're often the best way to model tree-structured data. - TMN

DVC5 - ER components - Approved

This is the first I have heard of Weak Entities. They seem very strange -- I have never heard of a table without its own primary key. How do weak entities map into a relational element in the database? Anyway, I agree it's low priority, I would suggest a P3, actually.

DVC6 - Graphically designing ER components - Approved

You split these up into a lot of bullets. I'd like to see each of these prioritized, not included as all or none under item 6

DVC7 - Set properties - Approved

You say "see table for provided properties" but the table seems to describe ER components, not properties. It would help if you labeled the table and perhaps put it under this bullet. Also, I'm not sure if the graphic adds much value.

I guess I think of components as something you create visually, using drag-and-drop or by drawing a line, and I think of properties as pieces of data that describe a component. So in my mind an entity and a relation are components, and attributes are properties of an entity. Also, a relation has properties too, like cardinality and the roles of the relation.

Thanks for fixing this, but now you have no list of what properties will be set. I'd like to see a list of properties that will be viewable/editable, and priorities. Here are so me ideas to get you started:

  • Properties for an Entity
  • Author
  • Description
  • Table name (if you want to specify how it should be mapped)

  • Properties for a Column/Field
  • Description
  • Primary key?

You get the idea - David

This looks good. I'm going to add some additional comments at the end of my comments based on what you put in here - David

DVC7.2 - Indexes - Approved

How do you capture information about what indexes you want to be generated?

DVC8 - Cardinality - Approved

I believe this is high priority, I don't know how you can generate a DB without knowing the cardinality

DVC9 - Composite and multivalued attributes - Approved

First I have heard of these too. How are these very non-normalized concepts mapped into a normalized relational model? What purpose do they serve when doing an E/R model. I definitely agree these are low priority

Multivalued attributes are used almost exclusively in data warehousing, where they are often used to represent time series of data values. For example, if you're examining production data, 95% of the time you just want granularity down to (say) monthly output by (plant/warehouse/line). So the database will have an entry for each plant for every month. However, it may also store daily production figures in a multi-valued column so that you can "drill down" to that level. That way, queries can easily reference the significant monthly production figures without having to sum them up from the distinct daily production numbers. I think they're a crutch, but I concede they do have their uses. - TMN

DVC10 - Preview diagram - Approved

What does this mean, exactly? Can you provide a short description?

DVC11 - Auto-align - Approved

Hopefully the graphical library will help with this - you might check with Trey. If this is hard to do, I say we can skip it.

Trey suggested looking at nb Visual Library which i think is the newer version of Graph library, isn't it? So that what we'll be doing next. -Wessam

I think this is the same thing, I'm not sure. Send an email to Trey (copying the list) to confirm. - David

DVC12 - Alter database rather than re-create - Approved

I would love to see this as a stretch goal. DDLUtils provides the support for this. I also found an interesting project called LiquiBase that does database refactoring. It's in open source under LGPL. I am checking with our legal folks to see if we can include it in NetBeans. If so, we should take a very serious look at this. This is a very common desire for our users.

The same goes for generating SQL that alters the database rather than re-creates it.

I'm glad we might have some resource on that cause this is one of the main add-ons that we'll be concentrating on doing after we finish the main features -Wessam

I'm working with legal to see if we can use this code, I'll keep you informed - David

DVC13 - Generating entity classes for a given language domain - Approved

I would like us to think about this a little bit more. NetBeans already has the ability to generate JPA Entity classes from a set of database tables. So it could take just a few tweaks to make this work in a seamless way, where in one step we (a) create the database tables and then (b) generate the Entity classes.

Note, by the way, that folks are asking for migration of Entity objects (e.g. don't regenerate with a new revision of database, but modify

I think this is one of many examples where, once we start putting this into NB, there will be opportunities for integration with the rest of NB. But one step at a time :)

we didn't know that we can generate entity classes from database tables in nb. Are you suggesting that we consider migration of entity classes? -Wessam

No, this isn't about migration, but about creating entity classes from the E/R diagram. But let's make this a stretch goal, we have enough to do already - David

DVC14 - Scenario 1 - Approved

Great job on these scenarios! I would like to suggest that you think about what the *user view* is and avoid describing internal implementation details. The reason this is important is it allows you to have options during implementation. The scenario should describe solely what we want the user to be able to do, not how we'll do it. For example, maybe DDLUtils won't work out for us -- we don't know yet.

Also, to make the scenario more readable, please show each step as a separate bullet -- that's pretty standard for use-case analysis.

So, for example, I would reword and reformat Scenario 1 as follows:

  • The user designs an ER diagram using drag and drop ER components.
  • The user clicks a menu button to generate the relational database from the diagram.
  • The system prompts the user to specify the type of the database from a list of supported databases.

==> Actually, this should be changed to "The system prompts the user to select an existing connection or create a new one". Let's re-use what we already have in the database explorer. Under this step, we should grey out any connections that are for databases that are currently not supported by the E/R module

  • The system generates the database.
  • The user views the generated tables in nb database explorer.

I know it used to contain alot of design detail but we couldn't help it 'cause we're jumping into how everything is going to happen. I think it looks neater now. Thanks for the comment. -Wessam

DVC14.2 Scenario 1 - Approved

I'm not sure viewing the database in DB explorer is really part of this scenario. You could do any number of things with a DB once you've created it. I suggest skipping this step.

DVC15 - Scenario 1 - What can go wrong - can't generate db - Approved

First of all, don't bother what we won't do (unless you put it in a footnote) -- it's distracting to the main point

Secondly, it's not sufficient to say "unable to generate db" and that's it. If there are failures, they should be reported to the log file, and then we can pop up a dialog saying "Unable to generate database. Please see log file for details".

Also, if it's an empty diagram, I think we can either quietly do nothing or pop up a dialog saying "can not generate a database from an empty diagram"

DVC16 - Scenario 1 - What can go wrong - user hand-modifies database - Approved

This isn't really an error condition, but just something that can happen. You described this well enough in the "what we're not going to do" section above.

DVC17 - Scenario 1 - What can go wrong - Approved

Here are some other things that can go wrong, and we have to consider some of these carefully:

  • The database is partially created, and then we encounter a failure. As a result, the user has a half-created database. We could try to automatically drop the existing tables as part of error recovery, but I would say let's not try to be too tricky in the first go. The user will need to clean out the database
  • The user does not have authority to create the tables or other elements. Nothing to do here but report the error

These didn't cross our minds, thanks for mentioning them. i've added them to the scenarios -Wessam

DVC18 - Scenario 1 - Approved

What should we do if there already exists tables in the database. What I've seen elsewhere (for instance, when copying to a directory) is the standard "A table of name 'foo' already exists, do you want to recreate it? [[ | ]] Yes [[ | ]] No [[ | ]] Do this for all tables" Alternately, we could have a check-box in the create-database dialog that allows the user to choose whether to overwrite or not. I prefer the former.

Of course, we may be at the whim of DDLUtils here, so some research may be needed to see what we can do and what is unachievable with DDLUtils.

I prefer the check-box approach. This can actually be encoded into the generated DDL (by querying the data dictionary or explicitly specifying DROP TABLE), so all the software has to do is generate the creation script and pass it off to the DB. Of course, if the software can alter the database instead of recreating it, this point may become moot. - TMN

DVC19 - Scenario 1 - UNRESOLVED

Perhaps we should allow the user to create a new schema or use an existing schema. I wonder what DDLUtils does here.

you mean we should allow the user to create the db from an sql schema without drawing the diagram? But, isn' t this supported by db explorer?can't we load a schema in db explorer and get the db? -Wessam

The terminology is confusing. A "schema" is used both to describe a set of tables, and the namespace that those tables live in. Some database vendors call this a "catalog". For example, in Java DB there is the APP schema. When you create a set of tables, you can create them in an existing schema (e.g. APP) or create a new schema for them to live in. - David

Still unresolved - are you going to mention choosing the schema vs. creating a new one?

I don't know what you mean by this. Which step do you mean by this? is it on generating the db or the diagram? -Wessam

DVC20 - Scenario 2 - Approved

Same comments on error conditions, formatting, internal implementation as with Scenario 2.

DVC20.2 - Scenario 2 - Approved

The term "SQL Schema file" is non-standard. You can just say "SQL DDL file"

DVC21 - Another potential use case - Approved

I just realized, we could also support creating an E/R diagram directly from SQL files. I wonder if DDLUtils can read from a SQL file into their format.

Again, if db explorer supports loading a schema and then getting the db, and we already support generating it from the db, then i think we can give the user this option. So instead of creating a connection to an existing db, we can have him loading a schema. Is this what you meant? -Wessam

No, I meant I select a .sql text file and generate an E/R diagram from it directly. But I think this is really non-intuitive and not needed, so never mind.

DVC22 - Scenario 3 0 - Approved

Same comments: avoid discussing internal implementation

DVC23 - Non-functional requirements - Approved

We probably need to have some metrics about how long it should take to perform key operations such as opening the diagram, saving the diagram, table generation and database import.

We should describe target times for a demo size diagram (5 entities) standard size diagram (maybe 20 entities) and for a larger one (e.g. 100 entities). I mention demo size because demos are important when trying to get people interested in the functionality, or when someone is trying to prototype and check out the tool.

Thanks for mentioning those too! How can we come about defining times for that? What type of constraints do we have here? Can we assume it to be fast, slow, moderate or do we base it on actual calculation? -Wessam

This is always challenging. The time is of course impacted by what kind of hardware you are running on. One can spend a lot of time getting very specific about this. I would say we should pick a "standard" developer machine, something with 2GB of memory and a 7200 rpm disk and a reasonably fast CPU. Then we decide what is "reasonable". I would expect a "demo"-sized diagram to take no more than a couple of seconds, a medium size take no more than 5 seconds, and a large one to take no more than 15 seconds. Would you agree? And this is a target, a goal. If we're close, we're OK. If we're far away, we have some work to do. - David

DVC25 - Data dictionary - Approved

Another requirement to note, though I don't believe it belongs in the initial implementation: the ability to generate a nice, readable data dictionary for the database. This takes advantage of additional metadata you can attach to entities and relationships that aren't stored in the underlying relational database schema.

i thought that this is done already in nb. what i know is that any DBMS keeps a catalog or data dictionary to keep metadata of databases. Obviosuly it's not the case. What do you think a data dictionary would add? And would why ppl need it? -Wessam

Data dictionaries are like Javadoc for your schema. It's nice to be able to see a table's columns with their data types (and especially descriptions, if the database supports this). It's very nice to be able to add them as an appendix to a design document. - TMN

you mention that there's additional metadata in the diagram that aren't stored in the underlying db. This makes me think of an important thing. does the metamodel of the diagram contain information that are extracted from the diagram that are sufficient to create the db? or does it contain all information in the diagram? and is there a reason it can't represent all what comes int he diagram? or the problem is in mapping this metadata to the db? I think things like cardinalities, weak entities and others aren't stored in the db because they're just conceptual representations. but each has a mapping rule by which you can map it to the db. So all information will be present in the db but with different format, with relational format rather than conceptual or abstract. -Wessam

A data dictionary is normally a nice PDF or ODF or HTML file that contains a full description of all the data elements. Many people document each and every table and field in the table with lots more information than you can put into the database. It's not just about concepts such as weak entity. You just can't capture all of this in the database definition, as there is no space for things like descriptions, comments, notes, authors, version history, etc. - David

I see you mention Data Dictionary in additional requirements, good enough, thanks - David

DVC26 - Scenario 1 - UNRESOLVED

You might want to take out the first step and make it a separate scenario. There are many ways whereby you can end up with an ER diagram. In other words, creating the tables is a separate step from creating the ER diagram

I agree to that. In the UI specs, which will be out soon, creating the diagram scenario is discussed in detail -Wessam

DVC27 - Properties - UNRESOLVED

It's confusing that you have two places to specify a primary key - on the attribute and as a type of index. You might want to skip showing the PK index as an index, as that is pretty much implied.

JB1 - Overall

Looks great so far. Some comments I have may be better suited for a functional spec.

Thanks JB for adding your comments -Wessam

JB2 - Overall

I'd like to see more diagrams in this Requirements doc. I think starting with pictures helps to create better designs

I agree pictures make sense for a design and interface specs, but not sure about requirements. What kind of pictures are you looking for? - David

soon we'll be adding UI specification that will include mockups for the scenarios and more detailed ones. -Wessam

JB3 - Core User Requirements

#1, do we want to be able to create an ERD-type of nbproject that just contains any persisted ER files ?

It seems to me that ultimately an ER definition could be used within a lot of different projects, similar to db tables today. I actually like Jim's suggestion of putting it in the Services tab, under Databases maybe. - David

Does adding it in the services tab require changing any of out initial assumptions or adding any? Should we be adding this to our reqs and consider it it UI spec? - Wessam

JB4 - Core User Requirements

I think #2 and #3 could be combined.  Is it #2 OR #3 as in "Generate the SQL DDL that corresponds to an ER diagram" or "Convert an Imported database from an ER diagram"

JB5 - Core User Requirements

Regarding the nbproject again, do we want to support one or multiple database connections per project?

Hm, I am having trouble understanding what an ER diagram for multiple connections would look like? My predeliction is to not support this in the first pass - David

Let me make sure i get this right. Do u mean that we might need to generate more than 1 database for 1 ERD? if that's the case, why do you think this is useful? Would it be useful for large diagrams maybe? -Wessam

JB6 - Core User Requirements

More on regarding the nbproject, do we want to support one or multiple ER diagrams per database connection?

Now this one sounds more interesting - each diagram representing some useful subset of the schema. I vote yes on this one, although maybe not for the first release - David

we'll be considering it as an add-on feature, thanks - Wessam

JB7 - Core User Requirements

#5, "Edit the generated diagram"  - "edit" consists of supporting create, cut/copy/paste ?

We just meant that the generated diagram won't be just for representation, but the user should be able to add/remove entities or edit any of the components' properties -Wessam

JB8 - Core User Requirements

related to editing a diagram, will there be properties for each ER component such that there is a NetBeans property sheet. To clarify, see the visualweb Designer when each component is added to the design there is a property sheet available that allows users to edit component properties

I would like to lean towards avoiding describing what this would look like in the requirements spec - it's enough to identify that there are properties. How they'll be represented can be handled in the UI spec - David

That's what we're planning to do. More on panes and palettes provided will be added in the UI spec. - Wessam

JB9 - Core User Requirements

related to JB8, if ER components have properties, which properties (id or name, relationships, cardinality, style property(color, bold), coordinates) ?

There is a delicate balance between specifying what we're committing to doing in this revision, versus getting too bogged into details. I'd like to hear others' opinions about whether specifying all supported properties belongs in the requirements spec, or better belongs in the UI spec? - David

We'll be providing just a table of what we think basic properties of theER components would be in the reqs. I think David you suggested that we do this. but in the UI spec we'll be giving more details about the properties pane -Wessam

JB10 - Core User Requirements

how to assign cardinality?, consider a property dialog for the entire diagram that lists the relationships of ER entities 

Again - isn't this a question for the UI spec? - David

JB11 - Core User Requirements

Consider to use the NetBeans Navigator to support additional actions on each ER component in the

diagram. See how visualweb uses the Navigator (named "Outline" in 5.5) to display a hierarchy of components and additional actions that can be applied to individual components

Thanks, we'll consider it - Wessam

JB12 - Scenario 1, Scenario 2

Suggest to list the steps and/or flowchart the flow (I prefer a flowchart)

we'll consider your suggestion but we'll be adding this to UI sepc , which will describe the user's experience in more detail with some mockups -Wessam

JD1 - Overall

Wessam asks: "Do you think this scope is fine, or we need to add to it?"

I think the scope is fine. This is the right amount of functionality to target for the initial implementation.

Thanks JD for adding your comments -Wessam

JD2 - Overall

I had many of the same comments as David, and I see you've already incorporated many of his suggestions into the document.

A couple of remaining points:

  • "deploy database" should be replaced by something like "build database" or "create database"
  • what does "Preview Diagram" mean?

JD3 - Introduction

I'm a little puzzled by the list in the introduction, which marks two functionalities as "optional" (Generate SQL schemas, Generate relational database).

Why are these items "optional"? Do you mean that you might not implement them? Or that they're optional for the user?

We need at least one of them in order for the tool to be useful.

We meant that the user if the user starts a new project only to design a diagram, then he's not obliged to generate the db or SQL, that would be optional for the user. But we're including it - Wessam

JD4 - Core Requirements

Something to think about:

Does an ER diagram necessarily need be part of a project? Or should we also support ER editing separate from projects, the way we do for some other database operations? We could put ER diagrams into the services tab.

For now, I don't think there's anything to change, but I would like to hear what readers of the list have to say on this. Maybe this could be an add-on.

I like this idea of making it part of the services tab - you're right, this is useful across project types and is independent of a particular project. Perhaps make it something under the Databases folder? - David VC

i understand that the services tab is used to allow for hosting independent services (like db conncetions, web services, and EJBs) in one project, is this right? JD, what do you mean "support ER editing separate from projects"? -Wessam

JD5 - Core Requirements

I would like to get a sense of how complete this is, with respect to the range of possible ER diagrams. Is there a de facto standard somewhere that enumerates all the constructs in the ER language and notation, or possibly a web site that covers the same information? Chen's work was targeted at mathematics more than usability, so that language has evolved since then. Maybe your table already includes all of the common constructs.

The tool does not need to support the complete set; rather, we need to be able to characterize the range of ER diagrams that we do/do not support.

There is more than one possible ER notation that we can support. The one we're proposing here is not the most naturally used by developers i guess, so we might end up supporitng another notation that is more UML like,and maybe later support is notation as another option for the user. -Wessam

JD6 - Core User Requirements

I have a few questions about the graphical components and the editing process. Some of these are details that can probably be covered during the spec/design phase:

In your list of components, you show four kinds of attributes (weak, key, composite, multivalued), but not plain attributes. You should probably include them for completeness.

yeah, that was one thing missing, thanks - Wessam

What kinds of properties will components have? I'm guessing that, e.g., an attribute's properties will include things like its name and type, right?

Mainly names and datatypes but a more complete list will be added soon - Wessam

Besides drag/drop, I assume the user will link things together, for example using relationships to link entities, right?

Yes, that's right. Relashionships are the connectors between the entities -Wessam

Is it possible to change the type of a component? E.g., Attribute -> Key Attribute

We were thinking of making the attribute as a seperate component (david thinks we should rather make it a property of the entity) and a property of that entity would be Category which defines whether the attribute is (key, multivalued, single,...) what do you think? - Wessam

Can the user specify database constraints via the ER diagram? I'm guessing that Primary Keys are expressed via Key Attributes, and Foreign Keys are specified via Relationships with particular cardinality, right?

Exactly that's how thry're mapped - Wessam

Will this support refactoring -- e.g., to move an attribute from one entity to another?

Refactoring is one of the top considered add-ons that we have as we had acouple of comments suggesting it -Wessam

JD7 - Add-On Features

I think your list is exactly right. These are some pretty hard issues, which are (in my opinion) much less important than the core functionality that you're proposing. We can prioritize later to decide whether to add them back.

There is one exception, listed next.

if you can help us with prioritizing them that would be great -Wessam

JD8 - Add-On Features

In the list of features that won't be supported in V1, you list:

'Automatic Associative Entity production

If the user specifies a many-to-many relationship, the system should automatically create an intermediary ("junction") table to implement the relationship.'

Let's look at that a little more. What if the user specifies a many/many relationship in the ER diagram? There's no way to map this into an RDBMS except with an intermediate table. How will we deal with that case?

That's what we meant here. If the user adds an M:N relashion on the ERD a junction should be automatically generated as if it's a new entity that's going to be mapped as a seperate table. Is this what you meant? -Wessam

This is an instance of a more general issue: could the ER diagram be more expressive than the database? I bring this up below in #10.

This is the only add-on that I'm concerned about for now.

JD9 - Scenario 1 & Scenario 2

These scenarios seem to be identical, except for the last step. Perhaps they can be combined, for clarity?

You're right. We just wanted to separate them to clarify that they are independent -Wessam

JD10 - Scenario 1

You cite a number of things that can go wrong: database error, authorization failure, etc. I'm not so concerned about all of these, since they arise with just about any application.

I did want to raise another issue: what if the ER diagram cannot be mapped into a database? That is, could the ER diagram express semantics that cannot be captured in the DB schema? There could be a couple of cases here:

  • the ER diagram could contain extra information (e.g., cardinality constraints that do not map into DB constraints)
  • the ER diagram could contain inconsistent information (e.g., data structures that cannot be represented in relational databases).

We could do a number of things, such as restricting the ER diagram editing so that the only valid diagrams are created. Or, we could return an error message at generation time (which is what you outline in the requirements). Or, we could just proceed with the generation process, and warn the user that information may have been lost.

What i know about the ER notation we're suggesting here is that everything on the diagram can be mapped to the physical DB tables but in "relational format". There's nothing in relational format called cardinality or relashionship, these are mapped as foreign keys. So i don't think there could be something on the diagram that i can't map to the DB. If you can think of anything that can't be represented in a relashional model from a conceptual model please mention it. I'll be checking on that -Wessam

JD11 - Scenario 2

Something to think about:

Should generation of SQL necessarily be tied to a specific DB? It seems that we could do something that was DB-agnostic, by using a subset of SQL that was common to most DBMS. I don't particularly like tying the application to a specific DBMS, any more than I like tying it to a specific application server. Or maybe let the user specify the version of SQL to support (SQL-92, SQL-99, SQL-2003)?

I don't think you need to make any changes here, but I want to hear whether anyone else has opinions on this.

If we're using something generic like DDLUtils, then it knows how to generate appropriate SQL for a number of target databases, and knows how to import metadata from those databases. I like this approach better: store metadata in a non-SQL XML format, and then generate SQL for a target datbase from that database-agnostic format.

JD12 - Scenario 3

Same as #10, but reversed: Is it possible that some information in the database or schema cannot be mapped into an ER diagram?

I don't know whether that would ever be the case; ER diagrams are pretty expressive. But, we may run across some features that don't map, especially if we support a subset of ER.

Hm. I was thinking that it would be OK for the ER diagram to capture more expressive semantics and then translate this into an implementation. If I were a developer, I'd like to use the ER diagram to understand the schema, as the database itself won't contain enough information. Not only extra features, but something as simple as a comment on an attribute or entity explaining its intent, documenting the overall intent of the schema, who the various authors are, etc., etc. So I don't think it should be an error if the ER diagram has more information than the underlying database, as long as the diagram can be *translated* into its manifestation in a database. - David

I think so too, I think that will always be the case. -Wessam

WGA1- Weak Entities

Weak Entities are like simple entities. Conceptually, a weak entity is an entity whose existance depends on another entity. For example, in a University database, a Course is a simple entity, while a Course-section is a weak entity because a course-section can't exist without a course. On mapping a weakk entity to the database, it's primary key is composed of the key of the entity it depends on and its own key. In case of Course and Section, Course primary key is (Course Number) while a Section's Primary key is (Course number,Section Numer)

WGA2 - Components Properties

you're suggesting to consider attributes as properties of an entity. actually we're considering attributes as components with seperate properties, like for example Category (simple, key,multivalue,composite) and also the data type (int, float,...). I know it could be easier to include it as a property of the entity, but this is the way we though of it.

WGA3- Composite and multivalued attributes

Composite attributes are used to show on the diagram that an attribute is defined as a composition of more than one attribute. For example, In an Employee entity, we can consider the Employee's name as a composite attribute that is composed of First name, Middle name and Last name. Actually on mapping this composite attribute to the database, First name, middle name and last name are mapped as usual columns and Employee's name is not mapped. So, it's just for visualization purpose.

Examples of Multi-valued attributes are Employee's Phones or Addresses which are attributes that can have more than one value. This allows an Employee to have more than one phone number and another employee to have no or less phone numbers because different people may have different numbers of values for the same attribute. Multivalued attributes are mapped as seperate tables with a primary key (key of the entity,the attribute) example Employee phones (Employee ID,Phone number)

Are you sure you want to handle multi-values attributes in this way? The SQL:2003 Foundation grammar defines the ARRAY qualifier for declaring multi-valued attributes. If you go about moving these attributes to other tables, then not only will you be confusing people, but the database you generate won't correspond to the model the user specified. Unless you're going to make people invoke some kind of "normalizer" process before they create the database. - TMN

Overall, this notation that we're proposing is complicated because it contains alot of conceptual components to it and mapping it to the database will be even more complicated. But that was the one in mind when we first started thinking about doing this module because that's the one we studied.

one of the things that we want to consider as an add-on is to support more than one notation. If we end up doing a simpler notation, we still will be willing to try support this one too.

The major concern is to support notations that most of developers are familiar with and would actually use. We depend on feedback to decide on the first supported notation.

WGA4- Preview diagram

it will be a pane that would be added to the UI in which the user can view the whole diagram at smaller scale. It's of lower priority than Adding Properties and adding/removing components -Wessam

TMN-1 - General comments

Overall, this document has improved tremendously. I think the scope has been pared down to reasonable (and reachable) goals, and shows that a lot more thought has gone into this project as a whole.

TMN-2 - Introduction

I agree with JD, I think labeling some of the functions as "(optional)" is disingenous. I would change the wording to "This extension will provide the user with the following capabilities:" or something similar.

TMN-3 - Scenario 1

In the "Hand-modifying the ER diagram" section, the spec states that if the ER diagram is modified and the database regenerated, then the new database doesn't overwrite the old one. I was wondering just how this was supposed to be accomplished. I can think of a couple of ways, but they'd require a lot of work and I was wondering just how useful this would be anyway.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo