“M” Samples Review: One-to-Many vs. Many-to-One

Isn’t this title funny? I like it 🙂

As I browse through the samples for the SQL Server Modeling CTP I find a lot of odd “M” code. This is sad, because Microsoft should know how to write “M” code. They are inventing it. Sure I’m expressing my personal opinion, but I think I have no hard time finding people that agree with me.

Why I do this in the “public”? Because I care! I like M and it’s concepts. For me M has the potential to become a great replacement for a variety of technologies. Most of all XSD, and maybe parts of SQL. That it comes with a SQL-code-generator is nice, though. But not too exciting. I still hope that the team adjusts their current direction. But more on that in a longer post 🙂

I’ll just start with one of the first samples I found:

Relationships

It comes with four M-Files:

asdf

 

 

 

 

 

So, what again is the difference between one-to-many and many-to-one?

OneToMany.m and ManyToOne.m

Well, this is OneToMany.m:

// original OneToMany.cs
module OneToMany {
    type A {
        Id : Integer32 => AutoNumber();
    } where identity Id;
    
    type B {
         A : A; 
    } where value.A in As;
    
    As : {A*};
    Bs : {B*};  
}

And this is ManyToOne.m:

// original ManyToOne.m
module ManyToOne {
    type A {
         B : B;  
    } where value.B in Bs;
    
    type B {
        Id : Integer32 => AutoNumber();
    } where identity Id;
    
    As : {A*};  
    Bs : {B*};
}

Do you spot the difference? I do! It would be easier to see, if we changed the ordering on the second one. Now compare this to the first one.

// reordered ManyToOne.m
module ManyToOne {
    type B {
        Id : Integer32 => AutoNumber();
    } where identity Id;
    
    type A {
         B : B;  
    } where value.B in Bs;
    
    Bs : {B*};
    As : {A*};
}

Do you see it now? Exactly. The XPath-function translate(‘AB’, ‘BA’) would have done the job! There is exactly NO difference between except for A and B switched around!

Usually the relationship the sample tries to illustrate is called one-to-many, even though in relational databases the reference goes from the many to one.

The funny part is over. Lets look at one-to-one and many-to-many.

OneToOne.m

This is OK. Although I do not like how coupled the code is. If I used the same style to express the same intent in C# people would blame me for violating every single principle we have learned over the past couple of years. I’ll write about what bothers me here in another post sometime.

// original OneToOne.m
module OneToOne {
    type A {
        Id : Integer32 => AutoNumber();
    } where identity Id;

    type B {
        A : A where value in As;
    } where unique A;
    
    As : {A*};
    Bs : {B*};
}

ManyToMany.m

// original ManyToMany.m
module ManyToMany {
    type A {
        Id : Integer32 => AutoNumber();
    } where identity Id;
    
    type B {
        Id : Integer32 => AutoNumber();
    } where identity Id;
    
    As : {A*};
    Bs : {B*};  

    type AB
    {
        ReferencedA : A;
        ReferencedB : B;
    } where value.ReferencedA in As && value.ReferencedB in Bs;
     
    ABs : {AB*};    
}

What is that. Natural modeling? What you really want to say is, that A has a n2m-Relationship with B, right? Now tell me, how this M-code is any better than SQL! It does not raise the level of abstraction, at least! IMHO this is not a solution for something that claims to be a modeling language, it’s a hack.

In“M” when you model something that naturally would be called a hierarchy or containment, the SQL compiler projects it as n2m anyway.

Relationship vs. Reference

Actually M doesn’t really support relationships (or associations) at all today. It just knows about references. What the difference is?

I’m not too sure if I get it right, but I’ll try.

A relationship is always coherent and integer. Something both sides agree on.

holding-hands1[1] 

A reference, though, is just something holding on something else.

detlef_46983[1] @Pitopia, Detlef

In relational databases relationships are modeled using references plus constraints.

So for example saying to the man, that he isn’t allowed to move as long as this baby holds his finger, you would enforce something that could be called an relation.

Summary

I think samples of this quality rather chase away people than buying them into the language. The language team should review all the documentation and samples. They should discuss them and give good guidance.

What I’ve seen so far is rather bad guidance.

Update: Also check out the MSDN Documentation on Relationships. It’s at least better than the samples. (found it after I wrote this post)

Advertisement

Points, inches and Emus: Measuring units in Office Open XML

After I got confused with the Office Open XML (OOXML) measuring units for a couple of hours, I thought I’d share what I found on it.

I order to avoid floating point calculations and still maintain high precision the format uses some odd measurement units. Don’t think you can get away with inches, centimeters or pixels!

UPDATE: I created a conversion tool for all those units, available here.

UPDATE 2: Just fixed the DNS, so the conversion tool should be available again quite soon 🙂

Twentieths of a point (dxa)

The main unit in OOXML is a twentieth of a point. This is used for specifying page dimensions, margins, tabs, etc.

The international default letter size is ISO 216 A4 (210x297mm ~ 8.3×11.7in) and expressed as this:

// pageSize: with and height in 20th of a point
<w:pgSz w:w="11906" w:h="16838"/>

Calculations

20th of a Point Points

(dxa/20)

Inches

(pt*72)

Centimeters

(in*2,54)

Width 11906 595.3 8,27… 21.00086…
Height 16838 841.9 11.69… 29.70036…

As you see it doesn’t really come out even, but even enough. As you can see here, word processes files at 72dpi.

Half-points

Half-points are used to specify font sizes. A font-size of 12pt equals 24 half points:

// run properties
<w:rPr>
  // size value in half-points
  <w:sz w:val="24"/>
</w:rPr>

Fiftieths of a Percent

This is used for relative measurements in some places. It can for example be used for specifying tables total with, cell with and margins.

<w:tbl>
    <w:tblPr>
      <!-- table width in 50th of a percent -->
      <w:tblW w:w="2500" w:type="pct"/>
    </w:tblPr>
    <w:tblGrid/>
    <w:tr>
        <w:tc>
            <w:p>
                <w:r>
                    <w:t>Hello, World!</w:t>
                </w:r>
            </w:p>
        </w:tc>
    </w:tr>
</w:tbl>

This prints a table that takes 50% of the available with. If you want to specify the with in twentieth of points instead, you have to use specify w:type=”dxa”.

Calculation

0.5 * 5000 = 2500pct

or

(50*50)%

EMUs (English Metric Unit)

EMUs are used for coordinates in vector-based drawings and embedded pictures. The EMU is a virtual unit to bridge both centimeters and inches. One inch equates to 914400 EMUs and a centimeter is 360000. Actually I found out that the number 914400 is calculated by (the least common multiple of 100 and 254) times 72. As I understand it, this ensures that you can convert forth and back between integer 100th inches, millimeters and pixels with out any floating points. Is that correct, anybody?

Since OOXML is too verbose, the full markup would just confuse even more. Lets say we have a picture that we want to fit into a table cell.

The cell with is 4,25cm which equals to 2410 dxa.

<w:tcW w:w="2410" w:type="dxa"/>

The original picture is 295x413px at 72dpi and is embedded using DrawingML. The target picture size in the document has to be specified twice. Once for the drawing canvas (extent) and a second time for the embedded picture itself.

When you try to draw this in word itself you’ll have a hard time to match the actual cell size. This version is set by manually calculating the target picture size.

<w:drawing>
    <wp:anchor ...>
        ...
        <!-- drawing canvas size -->
        <wp:extent cx="1530350" cy="2142490"/>
        ...
        <a:graphic>
            <a:graphicData>
                <pic:pic>
                    ...
                    <!-- shape properties -->
                    <pic:spPr bwMode="auto">
                        <!-- 2D transform -->
                        <a:xfrm>
                            ...
                            <!-- picture size -->
                            <a:ext cx="1530350" cy="2142490"/>
                        </a:xfrm>
                        ...
                    </pic:spPr>
                </pic:pic>
            </a:graphicData>
        </a:graphic>
    </wp:anchor>
</w:drawing>

Calculations

20th of a Point Points

(dxa/20)

Inches

(pt/72)

EMU

(in*914400)

Cell Width 2410 120.5 1,67361… 1530350

Even though this is the most logical way to calculate it, it involves floating points. You can simply avoid those by calculating:

2410 * 914400 / 72 / 20 = 1530350

which can be simplified to:

2410 * 635 = 1530350

Since we want to maintain the aspect ratio of the original picture at 295:413 we have to calculate the height for the cell in dxas and for the pictures in EMUs.

The width-to-height-ratio for this picture is 1.4. So the height for the cell is 2410*1.4 = 3374 dxa and 3374*635 = 2142490 emu.

Thanks for reading! I hope this helps.