I would like to create an ontology for MySQL database using protege, after that, I would like to map the database with the ontology.
Can anyone help me and send me any resources or example?
To map a relational database to an RDF dataset, you should create an R2RML mapping as described at https://www.w3.org/TR/r2rml/#dfn-r2rml-mapping.
Related
i would like to know if there is someone that can help me find the best way to manage a db with 50 tables that i assume has to be structured in my mvc application as multiple EMDX files for performance but that will have multiple connection strings that i hate.
So let's make a short example:
i have a join of 5 tables to create a customer list grid
and another 3 tables join for an employee grid.
I created two edmx context files to manage each grid and i have 2 connection strings.
Now, if i haev to create 30 grid will i have to create 30 edmx files and corresponding 30 connection strings?
The question is: is this the best practice for this? duplicating 30 times the connection string that connects to the same db?
Thanks
I am not sure why you need separate connection string. If you are connecting to same database then one connection string is enough.
Also if i understand correctly you are creating separate edmx file for each grid. This is not correct way of using Entity Framework. You should be using only one EDMX file for a database, 50 tables is not a big number. If you have complex query then i'll suggest to use store procedure and call it via Entity Framework using function import
One of my recent Rails app requires import data from excel, I've been following along Ryan's RailsCasts #396 Importing CSV and Excel, it worked out pretty okay, but with one limitation, I have to create the database schema first, just wondering how can I make it more adaptable, so that it could pick up any excel with any header or number of columns, base on the imported the data, to create database schema on the fly. Is that even possible? Thanks :)
Relational database works well when you know the structure of the data, there are not suitable for making migrations triggered by user data, if you don't know the structure you can always a schema like:
MyTable
col1: string
col2: string
col3: string
coln: string
Other approach you may try is to use a non-relational database like mongodb, it's compatible with ruby on rails.
Normally to create/alter a table in database I use migrations (manually run rake db:migrate) and then in my code I use ActiveRecord. This is very cool as I don't have to worry about representation of the data in db and about a specific kind of db (sqlserver, pg or other).
But now a customer wants to be able to create "things" on-fly himself like, say, he starts selling computers, so he wants to an interface where he can dynamically create an object "computer" with properties like "Name, RAM, HD, ...". It seems to be quite natural to create a separate table in db with all these fields. But how can I do that in RoR and keep all these nice things about ActiveRecord?
Please suggest.
The usual way is to do exactly the opposite:
Have a table for object types
Have a table for field names for each object type
Have a very big table with all the custom attributes for each object of any type
This is called EAV (Entity-attribute-value model, see http://en.wikipedia.org/wiki/Entity-attribute-value_model). And it scales pretty bad.
Alternatively, you can use a store text column instead of the big EAV table (see http://api.rubyonrails.org/classes/ActiveRecord/Store.html) so you don't have to make those difficult attribute retrievals, typical of EAV. You still need to store somewhere the "object types" definitions, so the expected fields etc are available when building forms and tables.
The problem with this approach is that you are not able to query (where/join/select) on those attributes because they are not columns. There are a number of solutions to that:
Don't do filtering on those attributes (meh...)
Have an external search server that's able to do faceted search
(as #Amar correctly says) Use a document database
Use postgreSQL and use hstore instead of a simple serialized column.
NoSQL database(Document Database Mongodb,CouchDB) can be best fit for this or use redis. As per my thoughts you can use Vertical Table concept Try to run Rails 2.x Demo of application for MySQL.
You can try with Mongodb, check if this is needed.
I have a MySQL database and would like to have a similar structure in Core Data. I am very new with using Core Data with Xcode. I have a few fundamental questions if I am doing the right thing.
My Mysql DB looks similar to this:
table.caveconditions
visibilityID
percolationID
xxxx
table.visibility
visibilityID
visibilityValue
...and so on. I would then connect the tables using JOINS
Now, I have done the Core Data modeling like this but I am not quite sure if this is the right approach.
Would be great if someone of you could tell me if this is the right way to do it. In the end I would like to use JSON strings to dump the mysql table into core data.
Thanks a lot
Chris
I have created the new schema. Is this right?
It looks good except for all the "xxxID" attributes e.g. caveID. You also need to follow the naming conventions.
You have the same attribute names with (presumably) the same values in two or more entities. This is necessary in SQL for joins but in Core Data, this is handled by objects and relationships.
Each object in Core Data is automatically universally unique. This means when you create a relationship from one object to another, that relationship concrete identifies on specific unique object.
This means you only need an attribute like caveID in the actual entity that caveID designates which in this case is (presumably) the Caves entity. You don't need the attribute in the CavesConditions entity or any other entity that has a relationship to the "Caves" entity.
(If the xxxID were just artifacts of SQL, you don't actually need them at in Core Data unless some external database your app interacts with requires them.)
A good rule of thumb to use is that any particular value should show up on only one side of a relationship and, ideally, only once in the entire data model.
Naming conventions are a little different than SQL. A Core Data entity isn't a table. An entity is more akin to a class. Each entity is supposed to describe a single instance of a managed object. How many of those instances end up in the object graph is irrelevant. Therefore, entity names are singular.
In this case, Caves should be Cave, Countries should be Country and so on.
Relationships are named after the entity they target. It is not immediate obvious but each reciprocal relationship (the default) on the visual data model editor is actually two relationships because there is one relationship description for each side. Each side has the name of the entity targeted. By convention to-one relationships have a singular name and a to-many relationship has a plural name.
So:
Caves.relConditions<-->>CaveConditons.getCave
...would become
Cave.conditons<-->>CaveConditon.cave
The naming conventions are important because Objective-C uses conventions names to generate and search for accessor methods.
CoreData is NOT a database. Remodel your data as simply as you can and in a way that suits how it will be used in your application and do not think about joins or structure based optimization. You do not have control over the backing schema of a CoreData object model. This is the hardest concept you must get over when starting to use CoreData, but once you do, you will be better off.
I was curious about how the MongoDB plugin for Grails would handle relationships. In order to test this I made a very simple application with two domain classes:
Authors have two fields: String firstName and String lastName
Books have two fields: String title and Author author
After setting up MongoDB and Grails I made some Authors and Books and took a peek using the MongoDB interactive shell. What I found is that the relationships were being handled the same way they would be handled in a relational database: references to other objects' id fields.
So now for the questions:
In order for GORM to pull this off, does it need a separate connection to retrieve each document?
If yes, wouldn't this be better off in a relational database such as PostgreSQL or MySQL?
If the answer to the above two questions is indeed 'yes,' then is there a better way to manage relationships in a document database such as MongoDB? I realize MongoDB isn't supposed to be relational, but there are some things that I don't see how to get around relationships without duplicating data (thereby making update nightmares).
Edit: I also just noticed that grails is not sorting properly on the 'id' property of my authors. Does this have to do with using MongoDB? In the shell I can see that the _id property of all the documents made by Grails is of the datatype NumberLong.
I realize MongoDB isn't supposed to be relational, but there are some things that I don't see how to get around relationships without duplicating data
Then don't sweat it. MongoDB is not anti-relational, it's document-oriented.
In this case, Books and Authors are two top-level objects. It's not reasonable to nest either of them, they are both core entities in their own right.
In the case of each Book having only one Author (N:1), it's completely reasonable for the Book to contain a "Reference To" the Author. Sure you'll have to do two queries. But is that terribly different from doing a join query? The join query still has to do two index look-ups and two data lookups. So you're not really costing yourself anything here.
In the case of each Book supporting multiple Authors (M:N), then you have several options based on your needs.
I don't like to think of MongoDB as "not relational", I think it's cleaner to think of MongoDB as query-optimized.
I also just noticed that grails is not sorting properly on the 'id' property of my authors...
I would check directly with the Grails author. Sounds like they may be storing "strings" instead of actual ObjectIds (or MongoIDs). While not critical this may be a bug.
In regards to the id property, the documentation now shows that you can put a declaration of ObjectId id or String id in your domain class in order to not use the default GORM implementation of using an iterating long. Simply declare the field in your class, and the plugin will take care of the rest.