I have an assignment for developing a hotel reservation system!
One of tasks is to develop UML class diagram! However, in the task description it is written
"Class diagram should represent your database"
I am a bit confused about the rules, notations and etc... because I can't find any official UML class diagrams specifically for databases!
Could you help me please?
Yes, the latest UML standards threw off the data diagram. Nowadays Entity Relationship Diagram is NOT the part of UML. But the Class diagram still is there in UML and it will be enough.
Simply make a usual class diagram. The only difference is that you shouldn't use n-to-m dependencies, instead make a new class between the ends and you'll have n-to-1 and 1-to-m dependencies instead. Such class diagram can be realized in a database. For better understanding in every class you can set an attribute id to be used in the DB later.
The other thing for such class diagram is that you need not to describe any methods - they don't belong to DB tables. But in the reality you need them - so, I'd create one easier diagram - with instantiable classes and without methods, and the other, more thorough - that one will include also abstract classes, interfaces and methods.
Also, on the first one you needn't put classes that belong to the UI - classes, that show your data and edit them.
First I would like to brief you about the different types of classes for a class diagram into which one can view the entire system in a static view.
Some classes are entity(model) classes which define the database model for application domain persist for longer duration. In the above mentioned case it can be customer, hotel staff, hotel menu, seating info.
Some classes define the GUI & presentation to the user such as view classes.
Some classes define the control the program logic, process user events which can be called as control classes.
Some classes can be viewed as the resource classes which are responsible for communication with external data resources.
For all the mentioned classes above the notations, rules followed in UML will be same but their usage, intent will be different.
For your problem, you need to capture these entity classes for the mentioned system through which you can model the database for your system.
I hope it will help you a bit.
The language of UML class diagrams can be used for many different purposes. For instance, for making
conceptual information models
platform-independent information design models
platform-specific data models for all kinds of executable languages dealing with data structures (including SQL and OO programming languages)
Each of these different types of models uses only certain UML class modeling elements, and not others. For instance, in SQL data models we don't use
visbility
interfaces
attributes whose type/range is another class
many-to-many (non-functional) associations
generalization
In fact, since SQL does not really have any explicit association concept, but only the concept of foreign key dependencies, which can be used for representing functional associations, we better shouldn't use any association in an SQL data model, but rather dependency arrows corresponding to foreign key dependencies.
It also makes sense to define two stereotypes for use in SQL data models:
«pkey» as an attribute stereotype for primary key attributes
«fkey» as a dependency stereotype for foreign key dependencies
See this tutorial for more information.
Related
As part of my research, I have been working on a DMN table and OWl ontology. I must map rules from the DMN table into an OCQA web ontology file and work later with SHACL to infer some rules.
In this process, as an initial step recently, my supervisor gave me a hint to map the DMN table with OWL.
His message:
"``https://www.omg.org/spec/DMN/1.2/About-DMN
You find an rdf specification on the bottom of the page.
First, you have to define the dmn schema in owl. Then you can directly define or import a dmn table into owl. Or you use the rdf schema."
I have very little idea about semantic web technology. So I studied some documents or tutorials and understood that classes, individuals, and relationships (object properties, data prop) made an ontology. Like this, I did practice an example development in Protege software also.
After his reply, I started to read what is an rdf scheme or OWL schema. But unfortunately, I didn't go further.
Can someone help me to understand the schema or help me define a relevant schema for the DMN table, as my supervisor suggested?
What should I do to define a schema? Is this nothing but making classes and individuals with relations or creating some placeholders and then getting them from the mapping of DMN? I am clueless. Should I use RDFPY library to do all these things?
"Stackoverflow is not supporting uploading DMN file. it is nothing but data in XML. below is the picture"
enter image description here DMN table for quality checks of a concrete curing method
Please, someone, help me to go further.
I would suggest making your schema in Protege. Your schema (ontology) will have a set of classes and properties between. Some ontologies will have named individuals, some will separate the named individuals out of the ontology. This is generally A-Box vs T-Box.
Personally, I use rdflib for python development but performance isn't great. For better performance you can use the redland python bindings - but it's a pain in the ass to work with.
As for your table... This is mostly an exercise in mapping from a relational data structure to a graph data structure. Each row represents a node of type 'Inspection' and has relations to the columns. For example consider the pseudo rdf,
Inspection_A rdf:type Inspection
Inspection_A hasActivity "Curing"
Inspection_A hasApprover "Site Engineer"
tldr; Your ontolgoy should have classes and relations (T-Box). Then in a separate file create instances of the classes (A-Box). T-Boxes will most likely be .owl files while the A-Box is turtle, nquads, json-ld, etc. When you load the two together in a graph database, it should be able to take the definitions in your T-Box and reason over your A-Box. You can use rdflib for programatically working with RDF. Your task is to map a table to a graph. The columns are relations, and table name is a class.
Given a problem specification, how to tell if it is a database design problem or class design(object oriented design) problem?
What comes to my mind, is that in OOP, classes(objects) contain methods, whereas a database is just a collection of relationships and values.
Therefore:
If you can say a problem is about how "things" in the specification relate to each other you have a database design problem.
If it is about what the "things" in the specification can do, you're going to be modeling more along object oriented programming.
If you're using a database and creating domain objects, it's both. Database design and class design are two different things, and both are necessary if you're using a database and classes. It's not like you choose one or the other.
This is where an ORM comes into play. When your data layer retrieves information from the database, a typical approach is to transform the relational data into your domain object(s) and pass that to the business logic layer so the rest of your application can deal with domain objects instead of a relational model.
Then your ORM does the opposite when persisting data: it takes a domain entity and turns it back into a relational structure that can be saved to the database.
Note: I'm assuming a relational database here. If not, substitute relational for whatever type of persistence layer you're using.
I believe that the only specifications which should be addressed as database-oriented problems are those which are focused on the manipulation of structured data types. If your specification is all about "store a customer record", "delete an order record", "change the value of price from 12 to 33 for record matching specifcation", you've got a database project.
I haven't seen that kind of problem specification since the Cobol team I worked in employed a systems ~~anarchist~~ analyst. Almost every project I've worked on since has had requirements that were not about how data was stored, but what the data meant.
If you get a requirement that says "Users may create Customers. Customers can place orders. Orders contain products. Orders can have delivery methods, payment methods, and status. Status follows a business process", you have an OO problem. You probably need a storage mechanism - and a database would be an excellent choice - but you have business logic that cannot be exclusively implemented by creating structured data types and relationships.
I'm a newbie with WPF/MVVM/Entity Framework and it's a lot of concepts to handle simultaneously.
I'm creating a WPF app with only one main View, which is splitted in 2 parts : 1 UserControl for a Master view of my data, another userControl for the detailed view. All data is stored in database generated via Entity Framework entity model.
So far I managed to do what I wanted (I use MVVM light) : databinding, commands, eventToCommand... I use following architecture in 1 VS project : 1 folder for Views, 1 for ViewModels, and 1 for Entities definition.
I pass data from master to detail userControl using MVVM Light Messaging, and when I try to update one entity, I encountered exception telling me that I can't update because I try to update one object linked to an ObjectContext (declared in MasterViewModel) with one object from another one (declared in DetailedViewModel)
How can I share EF ObjectContext between ViewModels? I read some stuff about repositories or UnitOfWork but I didn't really manage to see how I could use it in my case.
Subsidiary question : what's the best practice to access entities with EF and a n-tier app? Is the repository the answer? COnsidering the fact that classes already exists, should I have a "Model" folder in my solution architecture?
The answer is in the two design patterns you mention.
A Repository is a design pattern that helps you to create a single access point to your data. For example a CustomerRepository which has functions like GetById(int customerId), Update(Customer customer), Delete(Customer customer) and Add(Customer customer) and, depending on your specific flavor of implementing the pattern, other more specific functions for handling data that involves a customer.
In a regular application you would have a couple of Repositories that will give you access to different kinds of data. In a business function you would then use some of those repositories to build functionality.
Then the UnitOfWork pattern comes around, because this helps you to group a set of related operations. The Unit of Work keeps track of the changes until you save them to the database as a whole. (The ObjectContext in EF is an implementation of the UoW pattern)
In your example showing a master form and then loading and updating the details of one of those items, is a group of related operations that you want to update together.
This means that you should use one UoW for the master and the details view.
This is nice article which shows the basics of how an implementation of the Repository and UoW patterns could look like when using EF.
Here you can find an explanation of the Repository pattern and here of the Unit Of Work (those references are both from Patterns of Enterprise Applications, a really good book if you want to learn more)
I created for a project a single class, that contains all access code to the database.
Is this a good practice , under the assumption that this class doesn't contain any logic, or should i use several classes? If yes, how should i partition my code? I use C# .Net.
Actually Under the concept of MVC framework, it is a good practice to create a different class for database access, seperate class for logic and seperate class for your views.
You are doing good if you are writing a seperate class for database access under the assumption that it does not contain any logic.
In Agile Developement there is a term named as Database Encapsulation Layers.
A database encapsulation layer hides the implementation details of your database, including their physical schemas, from your business code. In effect this layer provides your business objects with persistence services – the ability to read data from, write data to, and delete data from – data sources. Ideally your business objects should know nothing about how they are persisted, it just happens. Database encapsulation layers aren’t magic and they aren’t academic theories; database encapsulation layers are commonly used practice by both large and small applications as well as in both simple and complex applications. Database encapsulation layers are an important technique that every agile software developer should be aware of and be prepared to use.
An effective database encapsulation layer will provide several benefits:
-> It reduces the coupling between your object schema and your data schema, increasing your ability to evolve either one.
-> It implements all database-related code in one place.
-> It simplifies the job of application programmers.
-> It allows application programmers to focus on the business problem and Agile DBA(s) can focus on the database.
-> It gives you a common place to implement data-oriented business rules and logic.
-> It takes advantage of specific database features, increasing application performance.
Hope this helps.
If your database is quite small, say, only a couple of tables, you could write all your queries in one class. otherwise I would suggest that per Entity/Table one class. for example, StudentDao.class will only focus on the queries to database table "STUDENT", and TeacherDao.class will only contain queries to table "TEACHER". if you are gonna implement a complex business logic, you may want to have a service class, to weave StudentDao and TeacherDao together.
Unless your data access is very simple, probably not.
you probably shouldn't need to write this code yourself. Take a look at some Object Relational Mapping tools. NHibernate is a popular .Net solution. http://en.wikipedia.org/wiki/NHibernate
If you really do want to write it yourself look up design patterns in this area, like the Data Transfer Object pattern. http://martinfowler.com/eaaCatalog/dataTransferObject.html
These are some of the suggestions while accessing database.
1.) Always keep your database access parameters in a properties file. Use a handler to get those data. Because when you change your database then you need not change your code just make a change in the properties file it's enough.
-- So here you need a handler class.
2.) Never create a single class (a god class) which performs all the actions. Disperse your behaviour in to different classes depending on the intent. For example Keep all read behavior in one class, Write behavior in another class ... so on.
3.) You can create a class which deals with connection creations and pooling stuff...
Hope this helps.
Not sure how to structure this. Model inheritance seems sensible, but it looks like Django will add a one-to-one link between the related models, which I don't need. Here's my situation: I have two models, for a Game and a Turn within a game. What I'd like to do is provide a "demo" version of these on my website for potential users to play around with. I want them to function just like the real models, but to populate different tables (eg say "demo_game" and "demo_turn") so I can clean them periodically and not "pollute" the real game/turn tables.
What's the best way to structure this? I could just copy the models to new versions, but would rather have a more elegant way to keep them in sync in case I modified one, but there is no need for any db relationship between a model and its demo version.
Create abstract base classes for each type, then derive concrete children.